Help! Namespace muddle

Discussion in 'XML' started by kj, Apr 13, 2004.

  1. kj

    kj Guest

    Consider the following XML document:

    <?xml version='1.0' encoding='UTF-8'?>
    <bar:foo xmlns:bar='someuri'>
    <baz/>
    </bar:foo>

    What namespace does baz belong to? What is this namespace bound
    to/associated with? My understanding was that baz above belongs
    to some "default default namespace", but I have not been able to
    find support in the standard for this. (If it's there I managed
    to miss it, and would be thankful if someone would tell me exactly
    where.)

    Now consider

    <?xml version='1.0' encoding='UTF-8'?>
    <foo xmlns='someuri'>
    <baz xmlns='some_other_uri'>
    <frotz/>
    </baz>
    </foo>

    Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?

    In general, in XML code that does not explicitly define any namespaces
    (not even default namespaces), what namespace do identifiers belong
    to?

    Thanks!

    kj

    --
    NOTE: In my address everything before the period is backwards.
    kj, Apr 13, 2004
    #1
    1. Advertising

  2. Hello, kj!
    You wrote on Tue, 13 Apr 2004 16:20:37 +0000 (UTC):

    k> <?xml version='1.0' encoding='UTF-8'?>
    k> <bar:foo xmlns:bar='someuri'>
    k> <baz/>
    k> </bar:foo>

    k> What namespace does baz belong to?

    It doesn't belong to any.

    k> What is this namespace bound to/associated with? My understanding was
    k> that baz above belongs to some "default default namespace",

    Why do you think so?

    k> but I have not been able to find support in the standard for this. (If
    k> it's there I managed to miss it, and would be thankful if someone would
    k> tell me exactly where.)

    k> Now consider

    k> <?xml version='1.0' encoding='UTF-8'?>
    k> <foo xmlns='someuri'>
    k> <baz xmlns='some_other_uri'>
    k> <frotz/>
    k> </baz>
    k> </foo>

    k> Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?

    The second, i mean some_other_uri namespace.

    k> In general, in XML code that does not explicitly define any namespaces
    k> (not even default namespaces), what namespace do identifiers belong
    k> to?

    They out of any namspace.


    With best regards, Alex Shirshov.
    Alex Shirshov, Apr 13, 2004
    #2
    1. Advertising

  3. In article <c5h40l$q3t$>, kj <> wrote:

    >What namespace does baz belong to? What is this namespace bound
    >to/associated with? My understanding was that baz above belongs
    >to some "default default namespace", but I have not been able to
    >find support in the standard for this.


    The "default default namespace" is no namespace.

    -- Richard
    Richard Tobin, Apr 13, 2004
    #3
  4. kj

    Ashmodai Guest

    kj scribbled something along the lines of:
    > Consider the following XML document:
    >
    > <?xml version='1.0' encoding='UTF-8'?>
    > <bar:foo xmlns:bar='someuri'>
    > <baz/>
    > </bar:foo>
    >
    > What namespace does baz belong to? What is this namespace bound
    > to/associated with? My understanding was that baz above belongs
    > to some "default default namespace", but I have not been able to
    > find support in the standard for this. (If it's there I managed
    > to miss it, and would be thankful if someone would tell me exactly
    > where.)


    It belongs to the default namespace, which is "no namespace". <baz/> has
    no defined namespace here.

    > Now consider
    >
    > <?xml version='1.0' encoding='UTF-8'?>
    > <foo xmlns='someuri'>
    > <baz xmlns='some_other_uri'>
    > <frotz/>
    > </baz>
    > </foo>
    >
    > Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?


    'some_other_uri'. The default namespace, i.e. the one with no prefixes,
    has been redefined in <baz/>, of which <frotz/> is a child element.

    > In general, in XML code that does not explicitly define any namespaces
    > (not even default namespaces), what namespace do identifiers belong
    > to?


    "no namespace". Even if you use prefixes which haven't been declared to
    reference a certain namespace before, the elements using them belong to
    "no namespace", or "undefined".
    This is explained in the XML Names TR at http://www.w3.org/ as far as I
    remember.

    A more interesting question is, in:

    <foo xmlns="someuri" xmlns:bar="some_other_uri">
    <bar:baz qux="some_value"/>
    </foo>

    What namespace does the attribute qux belong to?
    To my understanding it belongs to the bar-namespace (some_other_uri),
    although unprefixed.

    --
    Alan Plum, WAD/WD, Mushroom Cloud Productions
    http://www.mushroom-cloud.com/
    Ashmodai, Apr 14, 2004
    #4
  5. Ashmodai wrote:
    > kj scribbled something along the lines of:
    >
    >> Consider the following XML document:
    >> <?xml version='1.0' encoding='UTF-8'?>
    >> <bar:foo xmlns:bar='someuri'>
    >> <baz/>
    >> </bar:foo>
    >>
    >> What namespace does baz belong to? What is this namespace bound
    >> to/associated with? My understanding was that baz above belongs
    >> to some "default default namespace", but I have not been able to
    >> find support in the standard for this. (If it's there I managed
    >> to miss it, and would be thankful if someone would tell me exactly
    >> where.)

    >
    >
    > It belongs to the default namespace, which is "no namespace". <baz/> has
    > no defined namespace here.
    >
    >> Now consider
    >>
    >> <?xml version='1.0' encoding='UTF-8'?>
    >> <foo xmlns='someuri'>
    >> <baz xmlns='some_other_uri'>
    >> <frotz/>
    >> </baz>
    >> </foo>
    >>
    >> Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?

    >
    >
    > 'some_other_uri'. The default namespace, i.e. the one with no prefixes,
    > has been redefined in <baz/>, of which <frotz/> is a child element.
    >
    >> In general, in XML code that does not explicitly define any namespaces
    >> (not even default namespaces), what namespace do identifiers belong
    >> to?

    >
    >
    > "no namespace". Even if you use prefixes which haven't been declared to
    > reference a certain namespace before, the elements using them belong to
    > "no namespace", or "undefined".
    > This is explained in the XML Names TR at http://www.w3.org/ as far as I
    > remember.
    >
    > A more interesting question is, in:
    >
    > <foo xmlns="someuri" xmlns:bar="some_other_uri">
    > <bar:baz qux="some_value"/>
    > </foo>
    >
    > What namespace does the attribute qux belong to?
    > To my understanding it belongs to the bar-namespace (some_other_uri),
    > although unprefixed.
    >


    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

    --
    Cordialement,

    ///
    (. .)
    -----ooO--(_)--Ooo-----
    | Philippe Poulard |
    -----------------------
    Philippe Poulard, Apr 14, 2004
    #5
  6. kj

    Ashmodai Guest

    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.

    <foo xmlns="http://www.example.com" bar="qux"/>

    The attribute bar belongs to the same namespace here as foo (in fact
    XHTML works that way - otherwise all attributes in XHTML would belong to
    no namespace which obviously is NOT the case).

    That is why I'm unsure about the unprefixed attribute on a prefixed
    element case.

    In the following case:

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

    bar is unprefixed whereas its element is. That is where my problem comes
    from. Most documents with default namespaces you find on the net look
    like this:

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

    and assume baz belongs to the namespace of its element although it has
    no prefix and thus either defaults back to the unprefixed namespace or
    to "no namespace".

    However, logically in the following case:

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

    baz is an unprefixed element and as namespaces are not inherited from
    parent elements in the tree, baz belongs to the unprefixed namespace
    "http://www.example.net", not to its parent's namespace
    "http://www.example.com".
    (for example, in an XML Schema with the xs: prefix for the schema
    namespace, the contained elements will still be prefixed even though the
    root is prefixed already. unprefixed names belong to the default
    namespace (which may or may not be set) - this is because the prefix of
    an element is a reference to a namespace and if it is unprefixed, it
    belongs to whatever namespace has been defined for that).

    With the original example:

    <foo xmlns='someuri'>
    <baz xmlns='some_other_uri'>
    <frotz/>
    </baz>
    </foo>

    the unprefixed namespace is overwritten at baz and thus frotz belongs to
    'some_other_uri', not 'someuri'.
    Same happens with:

    <x:foo xmlns:x="someuri">
    <x:baz xmlns:x="some_other_uri">
    <x:frotz/>
    </x:baz>
    </x:foo>


    frotz belongs to 'some_other_uri' here as well.
    This is out of question.

    --
    Alan Plum, WAD/WD, Mushroom Cloud Productions
    http://www.mushroom-cloud.com/
    Ashmodai, Apr 14, 2004
    #6
  7. kj

    Ashmodai Guest

    In retrospect, attributes of prefixed elements don't need to be prefixed
    unless they belong to a different namespace than their element.

    <x:foo bar="qux"/>
    is as valid as
    <x:foo x:bar="qux"/>

    At least that is what the authors of the official schemas at W3C
    apparently think.
    Note that the only prefixed attributes most elements in official
    documents have are xml:lang, xml:base, etc, which have the reserved
    xml:prefix.

    When dealing with XLinks and so, you have attributes of the
    XLink-namespace which are being attached to elements of other
    namespaces. That is the sole reason they need to be prefixed.


    In the following:

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

    it is therefore wrong to assume baz defaults to the unprefixed namespace.


    ...

    Another case of self-education by spontaneous enlightenment as it seems.

    --
    Alan Plum, WAD/WD, Mushroom Cloud Productions
    http://www.mushroom-cloud.com/
    Ashmodai, Apr 14, 2004
    #7
  8. 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

    >
    > <foo xmlns="http://www.example.com" bar="qux"/>
    >
    > The attribute bar belongs to the same namespace here as foo (in fact
    > XHTML works that way - otherwise all attributes in XHTML would belong to
    > no namespace which obviously is NOT the case).


    no, bar has no namespace

    >
    > That is why I'm unsure about the unprefixed attribute on a prefixed
    > element case.
    >
    > In the following case:
    >
    > <x:foo xmlns:x="http://www.example.com" bar="qux"/>
    >


    bar has no namespace too

    > bar is unprefixed whereas its element is. That is where my problem comes
    > from. Most documents with default namespaces you find on the net look
    > like this:
    >
    > <foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
    > <x:bar baz="qux"/>
    > </foo>
    >


    baz has no namespace

    > and assume baz belongs to the namespace of its element although it has
    > no prefix and thus either defaults back to the unprefixed namespace or
    > to "no namespace".
    >
    > However, logically in the following case:
    >
    > <foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
    > <x:bar>
    > <baz/>
    > </x:bar>
    > </foo>
    >
    > baz is an unprefixed element and as namespaces are not inherited from
    > parent elements in the tree,


    and yet they are

    baz belongs to the unprefixed namespace
    > "http://www.example.net", not to its parent's namespace
    > "http://www.example.com".


    right

    > (for example, in an XML Schema with the xs: prefix for the schema
    > namespace, the contained elements will still be prefixed even though the
    > root is prefixed already. unprefixed names belong to the default
    > namespace (which may or may not be set) - this is because the prefix of
    > an element is a reference to a namespace and if it is unprefixed, it
    > belongs to whatever namespace has been defined for that).
    >
    > With the original example:
    >
    > <foo xmlns='someuri'>
    > <baz xmlns='some_other_uri'>
    > <frotz/>
    > </baz>
    > </foo>
    >
    > the unprefixed namespace is overwritten at baz and thus frotz belongs to
    > 'some_other_uri', not 'someuri'.


    right

    > Same happens with:
    >
    > <x:foo xmlns:x="someuri">
    > <x:baz xmlns:x="some_other_uri">
    > <x:frotz/>
    > </x:baz>
    > </x:foo>
    >


    right

    >
    > frotz belongs to 'some_other_uri' here as well.
    > This is out of question.
    >



    --
    Cordialement,

    ///
    (. .)
    -----ooO--(_)--Ooo-----
    | Philippe Poulard |
    -----------------------
    Philippe Poulard, Apr 14, 2004
    #8
  9. Ashmodai wrote:
    > In retrospect, attributes of prefixed elements don't need to be prefixed
    > unless they belong to a different namespace than their element.


    wrong

    >
    > <x:foo bar="qux"/>
    > is as valid as
    > <x:foo x:bar="qux"/>


    notice that validation is another question that is out of the scope of
    our problem

    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"/>

    >
    > At least that is what the authors of the official schemas at W3C
    > apparently think.


    they thought more certainly the same things that the authors of the
    official namespace recommendation at w3c

    > Note that the only prefixed attributes most elements in official
    > documents have are xml:lang, xml:base, etc, which have the reserved
    > xml:prefix.


    xml is a prefix automatically and systematically bound to
    "http://www.w3.org/XML/1998/namespace"

    however, it can't be override by the same or another declaration

    that is like if any xml document were defined the following declaration
    on its root element :
    xmlns:xml="http://www.w3.org/XML/1998/namespace"

    >
    > When dealing with XLinks and so, you have attributes of the
    > XLink-namespace which are being attached to elements of other
    > namespaces. That is the sole reason they need to be prefixed.


    XLink defines a grammar that "works" only thanks to attributes

    >
    >
    > In the following:
    >
    > <foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
    > <x:bar baz="qux"/>
    > </foo>
    >
    > it is therefore wrong to assume baz defaults to the unprefixed namespace.
    >


    baz has no namespace

    >
    > ..
    >
    > Another case of self-education by spontaneous enlightenment as it seems.
    >


    :(
    --
    Cordialement,

    ///
    (. .)
    -----ooO--(_)--Ooo-----
    | Philippe Poulard |
    -----------------------
    Philippe Poulard, Apr 14, 2004
    #9
  10. In article <c5j382$4gt$02$-online.com>,
    Ashmodai <> 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.

    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.

    The following example illustrates this:

    <foo:elem xmlns:eek:ne="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 xmlns:eek:ne="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.

    -- Richard
    Richard Tobin, Apr 14, 2004
    #10
  11. kj

    Ashmodai Guest

    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 fucked 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/
    Ashmodai, Apr 14, 2004
    #11
  12. kj

    Ashmodai Guest

    Also see:
    http://lists.w3.org/Archives/Public/xml-names-issues/1998OctDec/0013.html
    http://lists.w3.org/Archives/Public/xml-names-issues/1998JulSep/0087.html

    And more importantly:
    http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-expnames
    http://www.w3.org/TR/1999/REC-xml-names-19990114/#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:x="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/
    Ashmodai, Apr 14, 2004
    #12
  13. kj

    Ashmodai Guest

    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$-online.com>.

    [1] http://www.w3.org/TR/1999/REC-xml-names-19990114/#check-uniqattr
    [2] http://www.w3.org/TR/1999/REC-xml-names-19990114/#uniqAttrs
    --
    Alan Plum, WAD/WD, Mushroom Cloud Productions
    http://www.mushroom-cloud.com/
    Ashmodai, Apr 14, 2004
    #13
  14. kj

    Ashmodai Guest

    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$-online.com>,
    > Ashmodai <> 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 xmlns:eek:ne="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 xmlns:eek:ne="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/
    Ashmodai, Apr 14, 2004
    #14
  15. In article <c5k5sn$gk3$06$-online.com>,
    Ashmodai <> 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
    Richard Tobin, Apr 14, 2004
    #15
  16. kj

    Ashmodai Guest

    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/
    Ashmodai, Apr 14, 2004
    #16
  17. In article <c5k6n5$tsf$05$-online.com>,
    Ashmodai <> 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-names-19990114/#defaulting
    --

    Patrick TJ McPhee
    East York Canada
    Patrick TJ McPhee, Apr 15, 2004
    #17
  18. In article <c5k9v7$8mi$07$-online.com>,
    Ashmodai <> 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
    Patrick TJ McPhee, Apr 15, 2004
    #18
  19. kj

    Ashmodai Guest

    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/
    Ashmodai, Apr 15, 2004
    #19
  20. In article <c5m5sj$ssk$05$-online.com>,
    Ashmodai <> 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
    Patrick TJ McPhee, Apr 16, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Èý¹â
    Replies:
    1
    Views:
    567
    William F. Robertson, Jr.
    Jul 29, 2003
  2. Replies:
    0
    Views:
    5,129
  3. Anonymous
    Replies:
    3
    Views:
    531
    Ron Natalie
    Aug 18, 2003
  4. mwql

    Socket programming muddle

    mwql, Nov 26, 2005, in forum: Perl Misc
    Replies:
    3
    Views:
    154
    John Bokma
    Nov 26, 2005
  5. mwql

    Socket programming muddle

    mwql, Nov 26, 2005, in forum: Perl Misc
    Replies:
    3
    Views:
    117
    RedGrittyBrick
    Nov 27, 2005
Loading...

Share This Page