Help! Namespace muddle

[Ashmodai]

Re: Help! Namespace muddle

Richard Tobin scribbled something along the lines of:
<snip/>[color=blue]
> To say that it is in the namespace "http://www.example.com " is
> misleading, since it is not the same attribute as x:baz, which is in
> that namespace, and it does not have "http://www.example.com " as its
> namespace name.[/color]

I've figured out where my misunderstandin g came from, but anyway...
So you're saying baz has no namespace, but it does have a reference to a
namespace via its containing element?

My problem is that I'm used to treating references as replacements and
not as pointers. So to my original understanding the attribute had the
namespace of its containg element because it inherited it. I see now why
this is wrong, although I don't see why this decision (that namespace
defaulting doesn't work with attributes) has been made in the design.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions

http://www.mushroom-cloud.com/

[Patrick TJ McPhee]

Re: Help! Namespace muddle

In article <c5k6n5$tsf$05$ 1@news.t-online.com>,
Ashmodai <ashmodai@mushr oom-cloud.com> wrote:

% > i guess that you think that they are the same, whereas they are not;
% > what do you think about :
% > <x:foo bar="qux" x:bar="qux"/>
%
% As per [1] and [2] this is bad. Both attributes share the same namespace

Load a file into a namespace-aware parser and see what the parser
has to say about it. Try it out with an xslt processor. You'll find that
bar has no namespace, while x:bar has the same namespace as x:foo.

% (the first because it will be expanded as per [1] and the second because

Read [3], and notice where it says `Note that default namespaces do not
apply directly to attributes.' Now read [2] again. Notice the use of the
word prefix. Notice that the second example is essentially the same as
the one given above, and that `each of the following is legal, the
second because the default namespace does not apply to attribute names.'

[3] http://www.w3.org/TR/1999/REC-xml-na...14/#defaulting
--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

[Patrick TJ McPhee]

Re: Help! Namespace muddle

In article <c5k9v7$8mi$07$ 1@news.t-online.com>,
Ashmodai <ashmodai@mushr oom-cloud.com> wrote:
% Richard Tobin scribbled something along the lines of:
% <snip/>
% > To say that it is in the namespace "http://www.example.com " is
% > misleading, since it is not the same attribute as x:baz, which is in
% > that namespace, and it does not have "http://www.example.com " as its
% > namespace name.
%
% I've figured out where my misunderstandin g came from, but anyway...
% So you're saying baz has no namespace, but it does have a reference to a
% namespace via its containing element?

The attribute is interpreted in the context of its containing element,
so the namespace of the element has an effect on its interpretation.

The question you might be asking is why would it be useful for the
attribute to be in the namespace of its containing element?

--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

[Ashmodai]

Re: Help! Namespace muddle

Patrick TJ McPhee scribbled something along the lines of:
<snip/>[color=blue]
> The question you might be asking is why would it be useful for the
> attribute to be in the namespace of its containing element?[/color]

The question I might be asking is why all the nitpicking of whether an
attribute is a namespace or only interpreted in the namespace of its
containing element if the only thing that apparently is attempted to be
made clear here is whether the attribute is local to the element or
global to the entire namespace.
I don't think it makes sense to define within the XML document whether
an element is global or local, it should be done in the defining
document (XML Schema, DTD, RELAX NG, whatever).
Why can't a local attribute, which belongs to an element which may have
a namespace, just inherit the namespace from its parent if it's
interpreted "in the context of its containing element" (i.e. also in the
namespace of its containg element) anyway?

Having a namespace or not should not be what makes an attribute local or
global.

If we went by that rule, we should drop namespace defaulting altogether
and declare unqualified elements as to be interpreted in the context of
their parent element. Tada, local elements.

I'm not critizing you, I'm critizing the rec.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions

http://www.mushroom-cloud.com/

[Patrick TJ McPhee]

Re: Help! Namespace muddle

In article <c5m5sj$ssk$05$ 1@news.t-online.com>,
Ashmodai <ashmodai@mushr oom-cloud.com> wrote:
% Patrick TJ McPhee scribbled something along the lines of:
% <snip/>
% > The question you might be asking is why would it be useful for the
% > attribute to be in the namespace of its containing element?
%
% The question I might be asking is why all the nitpicking of whether an
% attribute is a namespace or only interpreted in the namespace of its
% containing element if the only thing that apparently is attempted to be

Because it makes a difference at the processing level. If you process an
XML file, you take name spaces into account, and you want to process the
file correctly, then it matters how unprefixed attributes are handled.
The reason for `all the nitpicking' is that you repeatedly insisted that
your totally incorrect interpretation was correct. For instance, based on
your advice, it would be impossible to write a correct XSL transformation
involving attributes.

% Having a namespace or not should not be what makes an attribute local or
% global.

And it isn't. _Every_ attribute is intepreted in the context of the
containing element -- not of its namespace, but of the element itself.
Even if the attribute has a namespace, its meaning can be tied to the
element of which it's a part. As it happens, the interpretation of
certain elements is fairly uniform, and attributes with namespaces
lead the way, but whether an attribute is `local' or `global' depends
entirely on how you use it.

% If we went by that rule, we should drop namespace defaulting altogether
% and declare unqualified elements as to be interpreted in the context of
% their parent element. Tada, local elements.

From a processing perspective, you can do this. You'll have a problem
validating against a DTD if you want to include parts of a DTD with
name conflicts, and of course that's the sort of problem namespaces
were meant to resolve. You don't typically have naming conflicts
with attributes, so you might ask yourself why it would be useful
for the attribute to be in the namespace of its containing element.

--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

[Ashmodai]

Re: Help! Namespace muddle

Patrick TJ McPhee scribbled something along the lines of:
[color=blue]
> In article <c5m5sj$ssk$05$ 1@news.t-online.com>,
> Ashmodai <ashmodai@mushr oom-cloud.com> wrote:
> % Patrick TJ McPhee scribbled something along the lines of:
> % <snip/>
> % > The question you might be asking is why would it be useful for the
> % > attribute to be in the namespace of its containing element?
> %
> % The question I might be asking is why all the nitpicking of whether an
> % attribute is a namespace or only interpreted in the namespace of its
> % containing element if the only thing that apparently is attempted to be
>
> Because it makes a difference at the processing level. If you process an
> XML file, you take name spaces into account, and you want to process the
> file correctly, then it matters how unprefixed attributes are handled.
> The reason for `all the nitpicking' is that you repeatedly insisted that
> your totally incorrect interpretation was correct. For instance, based on
> your advice, it would be impossible to write a correct XSL transformation
> involving attributes.[/color]

I wasn't talking about the nitpicking in this discussion, which does not
exist (stating the truth can hardly be called nitpicking).

Let me rephrase:
"The question I might be asking is, why does it matter whether an
attribute [..]?"

You answered that now.

I did not intend to criticize that you guys were defending a fact, I
only said it'd have shortened it a little if you had fully explained why
my perecption was wrong and what was right from the start. Also it
wouldn't have made me end up looking like a total standards-ignorant retard.
[color=blue]
> % Having a namespace or not should not be what makes an attribute local or
> % global.
>
> And it isn't. _Every_ attribute is intepreted in the context of the
> containing element -- not of its namespace, but of the element itself.
> Even if the attribute has a namespace, its meaning can be tied to the
> element of which it's a part. As it happens, the interpretation of
> certain elements is fairly uniform, and attributes with namespaces
> lead the way, but whether an attribute is `local' or `global' depends
> entirely on how you use it.[/color]

Give me a break, you're saying the difference between a prefixed and an
unprefixed attribute is that the prefixed one has a namespace and the
unprefixed one does not, but both get interpreted in the context of the
element? So how does <x:foo x:bar="1" bar="2"/> have any reason to exist?
What is the point of giving a local attribute a prefix? I'm not
questioning it, I just don't understand.
[color=blue]
> % If we went by that rule, we should drop namespace defaulting altogether
> % and declare unqualified elements as to be interpreted in the context of
> % their parent element. Tada, local elements.
>
> From a processing perspective, you can do this. You'll have a problem
> validating against a DTD if you want to include parts of a DTD with
> name conflicts, and of course that's the sort of problem namespaces
> were meant to resolve. You don't typically have naming conflicts
> with attributes, so you might ask yourself why it would be useful
> for the attribute to be in the namespace of its containing element.[/color]

So you too think <x:foo x:bar="qux"/> with bar being a local attribute
is a waste of markup?

OT#1:
What's the point of DTDs when working with namespaces? Doesn't that
pretty much defeat the purpose? I mean, other ways to reference entity
lists could be worked out and maybe some kind of schema catalog as well.
Won't schemas be used in favor of DTDs?

OT#2:
Isn't using French accents as quotation marks typographically incorrect
-- or have I totally misread something?
Imagine someone was reading Usenet messages with a TTS converter -- I
wonder how that would sound.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions

http://www.mushroom-cloud.com/

[J Krugman]

Re: Help! Namespace muddle

In <c5n995$nqj$1@n ews.eusc.inter. net> ptjm@interlog.c om (Patrick TJ McPhee) writes:
[color=blue]
>You don't typically have naming conflicts
>with attributes...[/color]

Why is that?

Are namespaces for attributes *ever* useful?

jill
--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.

[Richard Tobin]

Re: Help! Namespace muddle

In article <c5n995$nqj$1@n ews.eusc.inter. net>,
Patrick TJ McPhee <ptjm@interlog. com> wrote:
[color=blue]
>And it isn't. _Every_ attribute is intepreted in the context of the
>containing element -- not of its namespace, but of the element itself.[/color]

You might say that every attribute is interpreted by whatever
application you apply to the document, and it is possible for an
application to interpret an attribute without consideration of the
element.

For example, some kind of browser might look for xlink:type
attributes, and allow you to follow the corresponding xlink:href
attribute, without even determining the element name.
[color=blue]
>% If we went by that rule, we should drop namespace defaulting altogether
>% and declare unqualified elements as to be interpreted in the context of
>% their parent element. Tada, local elements.[/color]
[color=blue]
>From a processing perspective, you can do this.[/color]

And XML Schemas provide support for it: unless you use
elementForm[Default]=qualified, local element declarations validate
elements in no namespace.

-- Richard

[J Krugman]

Re: Help! Namespace muddle

In <c5ni3s$o44$1@r eader2.panix.co m> J Krugman <jkrugman@yahbi too.com> writes:
[color=blue]
>In <c5n995$nqj$1@n ews.eusc.inter. net> ptjm@interlog.c om (Patrick TJ McPhee) writes:[/color]
[color=blue][color=green]
>>You don't typically have naming conflicts
>>with attributes...[/color][/color]
[color=blue]
>Why is that?[/color]
[color=blue]
>Are namespaces for attributes *ever* useful?[/color]

Actually, I found a partial answer to my own question:

...the purpose of XML namespaces is to uniquely identify element
and attribute names. Unprefixed attribute names can be uniquely
identified based on the element type to which they belong, so
there is no need identify them further by including them in an
XML namespace. In fact, the only reason for allowing attribute
names to be prefixed is so that attributes defined in one XML
language can be used in another XML language.

(from http://www.rpbourret.com/xml/NamespacesFAQ.htm#q5_3)

I'm very inexperienced with XML; I can't think of a realistic
scenario in which one would want to use an attribute "defined in
one XML language" in "another XML language". Can someone point me
to examples of this?

Thanks!

jill

--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.

[Patrick TJ McPhee]

Re: Help! Namespace muddle

In article <c5pf2h$cmn$1@r eader2.panix.co m>,
J Krugman <jkrugman@yahbi too.com> wrote:

% I'm very inexperienced with XML; I can't think of a realistic
% scenario in which one would want to use an attribute "defined in
% one XML language" in "another XML language". Can someone point me
% to examples of this?

I was engaging in a bit of hyperbole a few messages ago, but in general
you do it because you want to define some sort of processing which
could be applied to a wide array of elements. An example from the standard
is xml:lang, which can be used to define the language of the content of
any element. In another message, Tobin gives xlink as an example. You
can create an XML document which acts as its own XSLT style sheet by
defining an xsl:version attribute, where xsl maps to the XSLT namespace URI.



--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

[Patrick TJ McPhee]

Re: Help! Namespace muddle

In article <c5nci5$l5a$00$ 1@news.t-online.com>,
Ashmodai <ashmodai@mushr oom-cloud.com> wrote:
% Patrick TJ McPhee scribbled something along the lines of:

% > And it isn't. _Every_ attribute is intepreted in the context of the
% > containing element -- not of its namespace, but of the element itself.

[...]

% > % Having a namespace or not should not be what makes an attribute local or
% > % global.

% Give me a break, you're saying the difference between a prefixed and an
% unprefixed attribute is that the prefixed one has a namespace and the
% unprefixed one does not, but both get interpreted in the context of the
% element?

What I'm really saying is that XML defines syntax, not processing. You say
that having a name space shouldn't be what makes an attribute global, and
I say that it doesn't -- the definition of XML has nothing to say on the
subject. You can process the data however you like without violating the
spec. Do whatever the hell you want. What XML says is that in this:

% So how does <x:foo x:bar="1" bar="2"/> have any reason to exist?

x:bar has a name space (presumably), while bar doesn't. Whether it has
any reason to exist depends entirely on what you're doing. I would never
have that, but that doesn't mean nobody would.

% What's the point of DTDs when working with namespaces?

They serve the same role as they do the rest of the time. The key to
having it work is to define the name space prefix as an entity, and
put all the definitions for each name space in its own file


<!-- x.dtd -->
<!ELEMENT %xpx;:foo EMPTY>
<!ATTRIBUTE %xpx;:foo %xpx;:bar CDATA #IMPLIED
bar CDATA #IMPLIED>

<!-- y.dtd -->
<!ENTITY % xpx "x">
<!ENTITY % x SYSTEM "x.dtd">
%x;
<!ELEMENT y (%xpx;:foo+)>
<!ATTRIBUTE y xmlns:%xpx; FIXED "http://www.x.org/xns">

% Isn't using French accents as quotation marks typographically incorrect
% -- or have I totally misread something?

There is no typographically correct way to specify quotation marks in
ascii. One lives within one's limitations.
--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om