Default namespace and attributes

Discussion in 'XML' started by John L. Clark, Dec 2, 2003.

  1. I am curious as to the rationale, and effect, of having default
    namespaces not applying (directly) to attributes (see
    http://www.w3.org/TR/REC-xml-names/#defaulting). Given an attribute
    without a namespace prefix, what is its namespace, if default
    namespaces do not apply? Are (either of) prefixed or non-prefixed
    attributes correct? For example, are the following equivalent:

    <html:br class="foo" xmlns:html="http://www.w3.org/1999/xhtml"/>

    and

    <html:br html:class="foo"
    xmlns:html="http://www.w3.org/1999/xhtml"/>

    If so, why? In the former, the class has no (or an empty?) namespace,
    while in the latter the class explicitly has the html namespace.

    Why would it make sense for attributes to not inherit namespaces as do
    elements? What does the specification mean when it says that default
    namespaces do not apply /directly/ to attributes?

    While I'm on the topic of namespaces, another little thing has been
    gnawing at the back of my brain. How can you determine when an
    included, namespace-scoped subtree is allowed to be included into the
    parent? For example:

    <html:html xmlns:html="http://www.w3.org/1999/xhtml"
    xmlns:eek:ther="http://some.other.namespace/">
    <!--Other elements to make the xhtml file valid can be put
    here...-->
    <other:foo/>
    </html:html>

    Now, obviously schemas corresponding to the html namespace have no
    knowledge of the "other" namespace, and so "other" elements shouldn't
    be allowed to arbitrarily populate an "html" tree. Where in the
    specifications is this sort of thing discussed? Are subtrees of one
    namespace invisible to the parent tree of a different namespace?

    Ok, true, this should really have been broken up into two threads, but
    I was on a roll, so I felt like just cruisin' through them both.

    Take care,

    John

    --

    Please note that you have no evidence that this message was sent by me
    <>, as it is not digitally signed. If you need to
    validate the authenticity of this message, do not hesitate to request
    a receipt by responding to this message with the original included.
     
    John L. Clark, Dec 2, 2003
    #1
    1. Advertising

  2. (John L. Clark) writes:

    > I am curious as to the rationale, and effect, of having default
    > namespaces not applying (directly) to attributes (see
    > http://www.w3.org/TR/REC-xml-names/#defaulting).


    Good question. Consider the following:

    - In most XML vocabularies, attributes are defined for
    specific element types, not globally for the vocabulary.
    - There are, however, exceptions: attributes intended for
    use on arbitrary elements (and meaningful even if used
    on elements in other namespaces).
    - If one takes the term 'namespace' as denoting a pool of
    identifiers which each uniquely denote some thing (e.g.
    locations in memory or functions), then it's clear that
    any XML vocabulary defined by a DTD has several distinct
    namespace: one for element types, one for general
    entities, one for parameter entities, and so on. Each
    element type, in turn, creates a distinct namespace for
    its attributes. On this understanding, it's clear that
    in the element <foo bar="baz"/>, the element type name 'foo'
    and the attribute name 'bar' are in distinct namespaces.
    Crucially, the 'bar' attribute of element 'foo' is
    quite distinct from the 'bar' attribute of any other element
    which might have one: different declaration, possibly
    different type, etc.
    - It seemed cumbersome but reasonable to require a prefix
    on the generic identifier (so we get <n:foo/>), but requiring
    a prefix on all the attributes as well seemed problematic:
    is it the same namespace? Not if a 'namespace' is a
    functional mapping from names to things: the 'bar'
    attribute of 'foo' is quite distinct from any 'bar' element
    which may be defined in the same vocabulary.
    Is it a different namespace? Well, not if we think of
    a namespace as containing, or being, a single vocabulary.
    And if we did make it a different namespace, then we'd
    end up needing a distinct prefix for the attribute namespace
    of each element. That, in turn, didn't seem attractive
    to anybody.
    - If we want to distinguish global from local attributes, it's
    convenient to say that local ones are always unprefixed,
    and global ones always prefixed.

    Given that the Working Group did not have any consensus on the nature
    of a 'namespace', nor any consensus about the desirability of greater
    clarity on the question, it is perhaps not surprising that we ended up
    by agreeing on something which has two rather different
    interpretations. We agreed that unprefixed attribute names are not
    namespace-qualified (if I may use these terms). Some WG members
    believed, I think, that that means "the attributes are not in any
    namespace", although there is nothing in the Namespaces spec which
    licenses the conclusion that unqualified elements and attributes are
    "not in a namespace". (All one can say is that the Namespace mechanism
    doesn't associate them with a namespace. Since the spec doesn't
    define what a namespace is or constrain it in any way, there isn't
    much opportunity for it to say that an unqualified item cannot be
    known by out of band methods to be "in" some namespace or other.)
    Other WG members believed, I think, that the attributes are "in" the
    namespace (or symbol space, as the XML Schema spec calls it)
    automatically created for the attributes of each element type; that
    namespace is not named, and nothing in the Namespaces Rec says much
    about it, but that means nothing in the Namespaces Rec can be used to
    prove that it doesn't exist.

    So, the main rationale and effect of the rule was to allow the WG to
    get the spec out the door before we killed each other or died of
    boredom with repetitive arguments.

    > Given an attribute without a namespace prefix, what is its
    > namespace, if default namespaces do not apply?


    It is not associated by the namespace spec with any namespace. This
    means (depending on whom you are talking to) either that it is not in
    any namespace or that its association, if any, with a namespace is
    achieved through means other than those defined in the namespaces
    spec.

    > Are (either of) prefixed or non-prefixed
    > attributes correct? For example, are the following equivalent:
    >
    > <html:br class="foo" xmlns:html="http://www.w3.org/1999/xhtml"/>
    >
    > and
    >
    > <html:br html:class="foo"
    > xmlns:html="http://www.w3.org/1999/xhtml"/>


    Not equivalent: the universal names of the two 'class' attributes are
    different. One has the pair ("http://www.w3.org/1999/xhtml","class")
    as its universal name, the other the pair (NULL, "class"), where NULL
    signals the non-existence of a value.

    > While I'm on the topic of namespaces, another little thing has been
    > gnawing at the back of my brain. How can you determine when an
    > included, namespace-scoped subtree is allowed to be included into the
    > parent? For example:
    >
    > <html:html xmlns:html="http://www.w3.org/1999/xhtml"
    > xmlns:eek:ther="http://some.other.namespace/">
    > <!--Other elements to make the xhtml file valid can be put
    > here...-->
    > <other:foo/>
    > </html:html>
    >
    > Now, obviously schemas corresponding to the html namespace have no
    > knowledge of the "other" namespace,


    How is this obvious? What is to prevent a schema from including
    components for both the html and the 'other' namespace? What is to
    prevent the content model for the html element from including a
    reference to the 'other:foo' element type?

    > and so "other" elements shouldn't
    > be allowed to arbitrarily populate an "html" tree. Where in the
    > specifications is this sort of thing discussed?


    The mechanisms by which a schema can comprise components for more than
    one namespace are described in the XML Schema specification. The
    specifics of what can occur in an HTML element, or in any element in
    any namespace, are discussed (if at all) in the documentation for the
    namespace in question and defined in the schema documents or DTDs for
    that namespace.

    > Are subtrees of one
    > namespace invisible to the parent tree of a different namespace?


    At the application level, they can be. At the XML level, or the
    level of validation using current schema languages, no, not
    invisible at all.

    I hope this helps.

    -C. M. Sperberg-McQueen
    World Wide Web Consortium
     
    C. M. Sperberg-McQueen, Dec 2, 2003
    #2
    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. VanOrton
    Replies:
    2
    Views:
    2,556
    VanOrton
    Nov 30, 2005
  2. Jason Heyes
    Replies:
    1
    Views:
    452
    Woebegone
    Nov 19, 2004
  3. Max
    Replies:
    2
    Views:
    485
    Joe Kesselman
    Aug 1, 2006
  4. P4trykx
    Replies:
    2
    Views:
    1,825
    bruce barker
    Jan 31, 2007
  5. Racinet Georges
    Replies:
    0
    Views:
    1,035
    Racinet Georges
    Jun 18, 2009
Loading...

Share This Page