Re: Use of QNames

[James Clark <jjc@jclark.com>]

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?

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)

- DOM Level 2 (namespace declarations appear as attributes)

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

- Infoset (in-scope namespaces property)

James