Re: Use of QNames

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

James Clark wrote:
> 
> Eric van der Vlist wrote:
> >
> > Before discussion list of simple data types, I'd like to raise the
> > question of the usage of a namespace prefix in a value:
> >
> > <element name="number" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
> >   <data type="xsd:integer"/>
> > </element>
> >
> > I think this construct isn't clean since it's creating a relation
> > between a namespace prefix and the content of an attribute.
> 
> Why do you think it's not clean for the content of an attribute to
> depend on a namespace declaration?

I hope I haven't been biased by 6+ years working on telecommunication
products and protocols, but I see XML as a layered system.

The first layer is XML 1.0 (I think it could itself be split into
several sub layers, but this is another story...).

The second layer are the namespaces and the third layer the applications
(that could themselves be split into several layers, especially if we
are to add features such as XLink, XInclude, ...).

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.

Despite the fact that it's hurting me as a violation of this layered
architecture, using namespaces prefixes in attributes or elements is
creating a dependency between these layers that is causing problems.

Two examples of such problems are the fact that canonical XML had to
step back from normalizing namespaces prefixes just because several
vocabularies would have been broken by a change of namespace prefixes
(IMHO it's reducing a lot the interest of a canonical form since it
cannot be used to say if 2 documents are similar when they are using
namespace) and the problems [1] Henry Thompson had to write a XSLT sheet
to transform April W3C Schemas to a new version.

[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2000Sep/0041.html

> > I know that it has been used by a number of applications, including XSLT
> > (but there, the context was different since the namespace declaration
> > was already needed for the literals) and W3C XML Schema.
> 
> I don't follow you here.

When I am writing 

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xhtml="http://www.w3.org/1999/xhtml">

One may expect that I will use the xhtml prefix both to qualify literals
and write:

<xsl:template match="/">
 <xhtml:html>
.../...

AND to qualify XPaths (select="/xhtml:html").

In other words, I see the motivation there as having wanted to kill two
birds with a single stone.

OTH, when I am writing:

<xsd:schema targetNamespace="http://www.w3.org/1999/xhtml"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" >

It is very likely that I will never use the xhtml prefix to qualify any
element or attribute of the schema document, but only to qualify schema
components with attributes:

<xsd:element ref="xhtml:myelement"/>

This is then an unnecessary abuse of namespaces prefixes and W3C XML
Schema could have used another way to define the relation between
prefixes and namespaces URI if they wanted to use prefixes.
 
It's what you have done with TREX and one of the first things I have
appreciated since I was working on this subject at this time.
 
> > Without starting a long rant, I think that, in the case of W3C XML
> > Schema, this is an error and that we shouldn't be following them.
> >
> > I would rather use something like:
> >
> > <element name="number">
> >   <data type="integer" role="http://www.w3.org/2000/10/XMLSchema" />
> > </element>
> >
> > (or type-system instead of role ?)
> 
> TREX already allows:
> 
>  <data type="integer" ns="http://www.w3.org/2000/10/XMLSchema"/>

This is different and, IMHO, clean since you are not using a namespace
prefix.
 
> This is not the only case where TREX allows names qualified by a
> namespace prefix.  They are also allowed in the
> 
> - name attribute of element
> - name attribute of attribute
> - name element
> 
> I regard this as an essential feature of TREX for working with patterns
> that mix multiple namespaces.  Having to specify the namespace URI
> repeatedly over the place is very error-prone: namespace URIs can be
> long and it's easy to make a typo; if you do make a typo, TREX can't
> detect that; the pattern would simply fail to match the documents that
> you thought it would.  I think it's very important to be able to define
> each namespace URI once, and then reference that definition.  XML
> namespaces allows this and we should too.  I believe removing QNames
> from TREX would significantly reduce ease of use.

The following example:

<element name="e:addressBook" xmlns:e="http://www.example.com">
  <zeroOrMore>
    <element name="e:card">
      <element name="e:name">
        <anyString/>
      </element>
      <element name="e:email">
        <anyString/>
      </element>
    </element>
  </zeroOrMore>
</element>

is, IMO, messier if it relies on a namespace declaration but would be
clean if 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.

Eric

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