Re: Use of QNames

[Eric van der Vlist <vdv@dyomedea.com>]

James Clark wrote:
> 
> Eric van der Vlist wrote:
> 
> > I see namespace prefixes as a trick to maintain compatibility with
> > QNames and avoid repeating a long ID and therefor a value that should be
> > private to the namespace layer.
> 
> I don't see why namespace declarations have to be private to the
> namespace layer.
> 
> > we could define another way to declare prefixes, such as:
> >
> > <namespace prefix="e" uri="http://www.example.com"/>
> > <element name="e:addressBook">
> >   <zeroOrMore>
> >     <element name="e:card">
> >       <element name="e:name">
> >         <anyString/>
> >       </element>
> >       <element name="e:email">
> >         <anyString/>
> >       </element>
> >     </element>
> >   </zeroOrMore>
> > </element>
> >
> > This would keep the same feature (using a prefix to qualify names) but
> > keep the TREX vocabulary independent of the namespaces prefixes than
> > cannot be finely controlled using current APIs or XSLT transformations.
> 
> That is certainly better than repeating the namespace URI all over the
> place, but I still don't see what is gained by inventing a new syntax to
> declare namespaces, when the XML namespaces Recommendation already has a
> perfectly good syntax for this. Why force the user to learn two syntaxes
> for the same thing?

I don't see it as the same thing. The namespace declaration is about a
prefix to be used within tag names. What we need here is to define a
prefix used within values and we would create a dependency between the
content and the envelope by using a namespace prefix.

I don't know how to say it, but I find it as shocking as using the name
of a parsed entity in an attribute or element.

This makes me think that this is actually something that could have been
done for namespaces, with the same process of reusing what has
previously been done, we could have avoided the pain of defining a new
way to associate namespaces prefixes with their URIs by using entity
declarations:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE myns:mydoc [
<!ENTITY myns "http://example.org/ns/">
]>
<myns:mydoc/>

I think that this would have created the same dependency --and the same
range of problems-- between different layers than using namespaces
prefixes within applications.

> The information that TREX needs about namespace prefixes is what
> namespace bindings are in scope.  This level of information is fully
> supported by major XML APIs and standards:
> 
> - SAX 2 (startPrefixMapping and endPrefixMapping methods on
> ContentHandler)

But still, what's coming ready for use in a startElement is the
namespace URI while you have to analyze the QName to extract the
prefix...
 
> - DOM Level 2 (namespace declarations appear as attributes)

Here again, getAttributeNodeNS gives you a local name and a URI and to
use getElementsByTagNameNS you need to provide a local name and a URI
while to get the prefix you need to handle it by yourself.

> - XPath/XSLT (namespace axis provides *exactly* this information)

The namespace axis is very weak compared to the other axis (you can't
apply templates on it and you can't easily replace a prefix by another
one) and it would be much easier to manipulate the syntax I have
proposed than a syntax based on namespaces declarations. 
 
> - Infoset (in-scope namespaces property)

But the Infoset isn't layered since it's a library of definitions that
can be used by any other specification for every layer.

> James

-- 
See you in Austin (Knowledge Technologies 2001)
              http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------