OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XML Schema Question: default namespace misses attributes

[ Lists Home | Date Index | Thread Index ]
  • From: rev-bob@gotc.com
  • To: xml-dev@xml.org
  • Date: 10 Feb 2000 10:25:44 -0500

> ** Original Sender: John Cowan <jcowan@reutershealth.com>
>
> rev-bob@gotc.com wrote:
> > [...] attributes should
> > "inherit" their element's namespace by default [...] the attribute is
> > in the element's namespace".
> 
> But these are not the same!

Semantic point here - the inheritance model here is mine, not part of
anything W3C did.  I then expanded on exactly what I meant by
"inheritance" in my model of How It Oughta Be.  Therefore, telling me
that I don't comprehend my own bloody model is nonsensical at best,
and incredibly rude at worst.  Now, OTOH, if you're trying instead to
say "that's not How It Is", well, I know that already.  Believe it or not,
I disagree with How It Is, and I'm trying to express my disagreement
in a logical form.

> Colon-free attributes are not in the *same*
> namespace as the element, but rather in a (sub)namespace *defined*
> by the element.  That's the rationale behind what the Rec says:
> there is no necessary connection between attribute foo in element A
> in namespace baz, and attribute foo in element B in namespace baz,
> but baz:foo is directly in namespace baz, independent of what element
> it appears in.

You misunderstand me somewhat; let's go for a concrete example.  Suppose
I'm writing my own supplemental DTD which defines elements "book" and
"navbar", among others.  I also have a second supplemental DTD - maybe
one I didn't write - that defines "book" as a different element.  My <book>
is shorthand for an Amazon.com link; as such, it is a container which requires
one attribute, called "code".  The other DTD defines <book> in, say, a
bibliographic context.  The two namespaces are going to be myDefs and
extraDefs, just for the sake of argument.  Now, at some point in one of my
documents, I want to use my Amazon.com shorthand:

<book code="0312862792">Riders in the Sky</book>

Clearly, I need to identify which version of <book> I want to reference.  That
means identifying the element's namespace:

<myDefs:book code="0312862792">Riders in the Sky</myDefs:book>

The question now becomes, what about the "code" attribute?  IMO, the
parser should see the myDefs namespace on the <book> element, and try to
find the "code" attribute in the myDefs definition of the <book> element first
- because that is the most logical step to take.  If that attribute is not found in
that definition, the next logical place to look is in the rest of myDefs - to see
if perhaps "code" is defined globally in that namespace.  In other words
(actually, the words I originally used), the "code" attribute should "inherit"
its namespace through the element which is using it if no other instructions
(ie. no namespace prefix) are present.

For my next trick, suppose I want to use some form of a global attribute in
that code fragment - HTML's "id" attribute is a perfect example of this
concept, being an attribute that every element can use.  Since this fragment
will appear in an XHTML document, let's say I want to make it the target
of a basic <a href> link.  Logically, the code should look like this:

<myDefs:book html:id="mq4" code="0312862792">Riders in the Sky</myDefs:book>

With that, I've explicitly identified HTML as the namespace for the "id"
attribute, because "id" cannot be found in the myDefs DTD - or maybe
I use "id" as a global attribute that means something else.  Thus, the
parser should grab <book> from myDefs, "code" from the section of
myDefs that defines <book>, and "id" from the HTML namespace as its
default first shot at handling this code.  No namespace prefix should be
required for "code", as it is tightly bound to the definition of <book> - it's
like requiring an html: prefix on the src, height, and width attributes of
<img>; that makes no sense.  As I understand it, namespaces exist to
identify changes and unusual cases, not to reassure the parser that every
attribute an element normally uses can be found in the definition of that
element.  That's the norm; we shouldn't have to use special-case syntax
to handle normal cases.

Now, who wants to pick this apart?



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS