Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > XML > Help! Namespace muddle

Reply
Thread Tools

Help! Namespace muddle

 
 
Ashmodai
Guest
Posts: n/a
 
      04-14-2004
Philippe Poulard scribbled something along the lines of:
> Ashmodai wrote:
>
>> Philippe Poulard scribbled something along the lines of:
>>
>>> hi,
>>>
>>> unprefixed attributes don't belong to any namespace !
>>> so, qux doesn't belong to any namespace
>>>
>>> the only way to bound an attribute to a namespace is to use a prefix

>>
>>
>>
>> Yes and no. Unprefixed attributes on unprefixed elements which belong
>> to a namespace belong to the same namespace as their elements.

>
>
> mmmh, that's quite wrong
>
> please have a look at the specification
> http://www.w3.org/TR/1999/REC-xml-names-19990114/
>
> in particular, chapter 5.3 will enlight you on attributes


Hm, probably another case of effed up recs. Maybe we should get an
official say on this - if "the default namespace does not apply to
attribute names" as the rec says, the W3C really ****ed up (sorry) big
time. Especially because they keep on violating this rule in every
single file they have online.

I think it's an error which slipped through. The CSS recommendations
also contain contradicting statements although they have reached
recommendation status with the flaws still present.
I will ask in the mailing list, it is likely they are able to solve that.

> <snip/>


I'd say we should leave it at that. You are right with what the
namespace says, but I don't think that's the correct intended behavior,
especially as all schemas and XHTML files and so on the W3C ever
released violate this convention [1].

[1] EX: http://www.w3.org/MarkUp/Forms/2002/XForms-Schema.xsd
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/
 
Reply With Quote
 
 
 
 
Ashmodai
Guest
Posts: n/a
 
      04-14-2004
Also see:
http://lists.w3.org/Archives/Public/...tDec/0013.html
http://lists.w3.org/Archives/Public/...lSep/0087.html

And more importantly:
http://www.w3.org/TR/1999/REC-xml-na...4/#ns-expnames
http://www.w3.org/TR/1999/REC-xml-na...check-uniqattr

The local attributes automatically have the namespace of their
containing element (A.3 - especially note the lines 4 and 5 in the first
example and line 4 in the second one).

That explains why you are wrong:

> Ashmodai wrote:
>> <foo xmlns="http://www.example.net" xmlns="http://www.example.com">
>> <x:bar baz="qux"/>
>> </foo>

>
> baz has no namespace


<x:bar baz="qux"/> is expanded (per A.3) as follows:

<ExpEType type="bar" ns="http://www.example.com" />
<ExpAName name='qux' eltype="bar" elns="http://www.example.com" />


...

Hah! I win!

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/
 
Reply With Quote
 
 
 
 
Ashmodai
Guest
Posts: n/a
 
      04-14-2004
Philippe Poulard scribbled something along the lines of:
<snip/>
> notice that validation is another question that is out of the scope of
> our problem


I wasn't talking about validation, I was talking about correctnes. Valid
may not have been the apropriate term, but I was not thinking of
validation in the terms of per-DTD validation, which I personally deem
inferior and deprecated when dealing with modern XML.

> 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
(the first because it will be expanded as per [1] and the second because
it shares the prefix of its containing element and thus has the same
namespace as the first one).

Actually I'm not entirely sure. The recommendation seems to be as
contradicting as the CSS 2 spec when it comes to attributes.
Ah, well, it's not important whether the attribute really is in the
namespace as long as it is expanded properly. If that didn't work out
right, XMLNS had no chance of survival.

Also see my earlier reply <c5k5sn$gk3$06$(E-Mail Removed)-online.com>.

[1] http://www.w3.org/TR/1999/REC-xml-na...check-uniqattr
[2] http://www.w3.org/TR/1999/REC-xml-na...114/#uniqAttrs
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/
 
Reply With Quote
 
Ashmodai
Guest
Posts: n/a
 
      04-14-2004
I don't know why my mail program (no, it's not OE) thought I was
replying to YOUR post when I wasn't, but anyway.

Richard Tobin scribbled something along the lines of:
> In article <c5j382$4gt$02$(E-Mail Removed)-online.com>,
> Ashmodai <(E-Mail Removed)> wrote:
>
>>>unprefixed attributes don't belong to any namespace !
>>>so, qux doesn't belong to any namespace
>>>
>>>the only way to bound an attribute to a namespace is to use a prefix

>
>
>>Yes and no. Unprefixed attributes on unprefixed elements which belong to
>>a namespace belong to the same namespace as their elements.

>
>
> This is one of the most confusing issues about namespaces. The
> original Namespaces 1.0 spec talked - in a non-normative appendix -
> about per-element namespace partitions, which are effectively
> sub-namespaces. Most later specifications - notably XPath/XSLT - did
> not use this language: in fact, they rarely talked about names being
> in namespaces at all; instead they talked about
> namespace-name/local-name pairs (expanded names). In that
> terminology, unprefixed attributes have a null namespace name, and it
> is natural to say that they are in no namespace.
> The key point about unprefixed attributes is that their interpretation
> is controlled by the element they appear on. Prefixed attributes on
> the other hand are intended to be "global": they mean the same
> regardless of what element they appear on.


"the interpretation of unprefixed attributes is determined by the
element on which they appear." (Namespaces in XML 1.1)

Seems you're right.

The explanation is all but satisfying tho.

> Unfortunately nothing guarantees (or even implies) that the global
> attribute foo from http://example.org namespace means the same as the
> unprefixed foo attribute on an element from the http://example.org
> namespace.


I think the editors went kinda overboard here. The recommendation
creates more problems than it solves - or so it seems to me.

> The following example illustrates this:
>
> <foo:elem xmlnsne="http://example.org"

xmlns:two="http://example.org"
> one:foo="abc" two:foo="xyz"/>
>
> is illegal, because it has two attributes with local name "foo" and
> namespace name "http://example.org", but
>
> <foo:elem xmlnsne="http://example.org"
> one:foo="abc" foo="xyz"/>
>
> is legal: one:foo and foo do not have the same namespace name.
>
> So to summarize, unprefixed attributes are in no namespace; their
> namespace name is null, or has no value. Their interpretation is
> determined by the element they appear on, and that interpretation may
> be different for different elements from the same namespace.


To summarize, unqualified (unprefixed) attributes are in no namespace,
but they are local to (i.e. belong to) their containing element, which
can have a namespace?

And I thought these guys had no humor.


...

I give in, your explanation apparently is the right one. It would have
saved a lot of time if someone had just given the actual reasons a bit
earlier rather than just talking binary.

Thanks for educating me. I'm not happier, I still think the namespaces
rec is faulty, but at least now I know for sure what it is trying to
express, although I do not agree with it.

Thanks, mate.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      04-14-2004
In article <c5k5sn$gk3$06$(E-Mail Removed)-online.com>,
Ashmodai <(E-Mail Removed)> wrote:

><x:bar baz="qux"/> is expanded (per A.3) as follows:


><ExpEType type="bar" ns="http://www.example.com" />
><ExpAName name='qux' eltype="bar" elns="http://www.example.com" />


(You mean name='baz', not name='qux'.)

(a) That appendix is non-normative.
(b) You will notice that baz does not have an "ns", which x:baz would.

In the terminology of the appendix, baz is in a namespace associated
with the element type "bar" in the the namespace "http://www.example.com".

In the terminology normally used today, baz is in no namespace. Its
namespace name is null, or has no value.

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.

-- Richard
 
Reply With Quote
 
Ashmodai
Guest
Posts: n/a
 
      04-14-2004
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 misunderstanding 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/
 
Reply With Quote
 
Patrick TJ McPhee
Guest
Posts: n/a
 
      04-15-2004
In article <c5k6n5$tsf$05$(E-Mail Removed)-online.com>,
Ashmodai <(E-Mail Removed)> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Patrick TJ McPhee
Guest
Posts: n/a
 
      04-15-2004
In article <c5k9v7$8mi$07$(E-Mail Removed)-online.com>,
Ashmodai <(E-Mail Removed)> 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 misunderstanding 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
(E-Mail Removed)
 
Reply With Quote
 
Ashmodai
Guest
Posts: n/a
 
      04-15-2004
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
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/
 
Reply With Quote
 
Patrick TJ McPhee
Guest
Posts: n/a
 
      04-16-2004
In article <c5m5sj$ssk$05$(E-Mail Removed)-online.com>,
Ashmodai <(E-Mail Removed)> 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
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ERROR CS0234: The type or namespace name 'DataAccessHelper' does not exist in the namespace 'BCC' (are you missing an assembly reference?) li.eddie@gmail.com ASP .Net 0 01-06-2006 11:31 AM
Socket programming muddle mwql Perl Misc 3 11-27-2005 02:47 PM
Socket programming muddle mwql Perl Misc 3 11-26-2005 03:46 AM
[XML Schema] Including a schema document with absent target namespace to a schema with specified target namespace Stanimir Stamenkov XML 3 04-25-2005 09:59 AM
Help:Why can't I use namespace System.Web? It is said that this namespace doesn't exist. But it should exist. ASP .Net 1 07-29-2003 04:31 PM



Advertisments