Re: Use of QNames

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

James,

I enclose a last try to better explain what I feel about the issue, but
I wonder if it's worth to continue arguing on a point nobody seems very
interested in and on which we will probably not find an agreement.

If I haven't convinced you yet, we can probably stop this thread and
just record that we don't agree on this point.

Sorry to be such a hurdle !

Eric

James Clark wrote:
> 
> Eric van der Vlist wrote:

> > The only solution that seems to be left is to define a new namespace
> > prefix (for instance in the top level element if I accept to write it as
> > a literal and/or to add a dummy attribute somewhere that would be using
> > it) and to analyze all the attributes that can hold a namespace prefix
> > to change their prefix when needed.
> 
> Right. This is a case that XSLT v 1.0 doesn't handle conveniently as it
> might. I expect XSLT v 2.0 will provide a way to construct namespace
> nodes explicitly.  Are you really saying that the design of TREX should
> be influenced by the fact that is room for improvement in XSLT 1.0's
> handling of namespace nodes?

No, of course not.

<note>
If I wasn't arguing with the editor of XSLT 1.0 who has influenced the
design of the namespaces, I would say that XSLT 1.0 is the W3C spec for
which I have the greater respect and that I'd rather be influenced by
XSLT 1.0 than by W3C XML Schema and that I see the way namespaces are
handled by XSLT 1.0 as a sign that it was considered as an opaque layer
at that time...
</note>

I was answering this specific point:

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

by showing that:

  - SAX and DOM do provide access to the namespace prefix but 
    they do it out of the main functions (startElement for SAX 
    and getAttributeNodeNS for DOM) though mechanisms that look 
    like out of band signals.

  - XSLT 1.0 provide a limited support to access and transform
    this information.

  - Infoset is a global (not layered) catalog and the fact that
    it's mentioning namespaces prefixes is not relevant.

I see this both as signs that these APIs and standards are implying a
usage of namespaces prefixes that is private to the namespaces layer
while providing separate APIs to access this layer for the applications
that need to do it.

> > I think I have burnt most of my arguments, especially if you don't
> > answer my points about the architecture...
> 
> I thought I had. 

Sorry, then.

> You say the architecture should be cleanly layered.  I agree.

> You assert that namespace declarations are private to the
> namespace layer.  I say they are not private. 

:(

> I provide evidence of numerous core XML specs that make information 
> about namespace declarations available outside the namespace layer 
> (DOM2, SAX2, XSLT, XPath). 

Yes, but they are supported through "out of band signals" meaning more
complexity for the developers.

> As a matter of observable fact, namespace declarations are not
> treated as private to the namespaces layer by the XML world. This issue
> was discussed at great length inside the W3C; various people argued,
> like you, that namespace declarations should be private. They failed to
> carry the argument. 

Sorry to be reinventing the wheel. I wasn't aware of these discussions.

There have been at least 3 recent events that should have helped them to
carry the argument:

1) The pimple XPointer has to add to declare namespaces within a URI
when the XPath expression is using QNames.
2) The drawback from XML Signature that had given up normalizing
namespace prefixes.
3) The fact that a generic XSLT transformation cannot be developed to
migrate W3C XML Schema version N to W3C XML Schema version N+1.

> This is not a situation that is going to change and so we should 
> adapt to it, even if we would have preferred that this
> situation had not arisen.  There's no benefit in TREX alone taking the
> position that namespace declarations are private to the namespaces
> layer, when everything else make them public. 

Except if we can find a syntax that doesn't use them and makes the life
of the implementers easier while not adding significant complexity for
the authors of TREX patterns.

I think that this is the case here since we do not need these
declaration to actually use namespaces, but only to shorten our syntax.

In other words I feel like if we were accepting to use a bad design
without real need to so so.

There might be applications that have no choice and for which the
decision is justified, I just feel that it isn't the case here and that
"conventional" XML solutions could be used without much impact for the
authors.

> Also note that most TREX implementations in practice will want to 
> support Schema Datatypes, which means supporting the QName datatype, 
> which requires information about namespace declarations.

That's what my proposal was trying to achieve:

<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 is already a compromise since 

<element name="email" namespace="http://www.example.com">

or (ala RDF or XLink)

<element name="http://www.example.com#email">

or

<!ENTITY e "http://www.example.com#">
.../...
<element name="&e;email">

or (ala XLink + XMLBase)

<element xml:base="http://www.example.com" name="#email">

(or pure XLink)

<element xlink:href="http://www.example.com#email">

Would IMHO be cleaner while carrying the same semantic and being still
compatible with W3C XML Schema data model but more different in their
syntax.

By cleaner, I mean that an application or an author doesn't have to go
though an indirection to figure out what a prefix means before
understanding the meaning of a name and also that this can be written
and parsed using straightforward XML practices --except for an authors
who would voluntarily chose conciseness against readability the
alternative using entities that is transparent for the application.

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