Re: Use of QNames

[James Clark <jjc@jclark.com>]

Eric van der Vlist wrote:
 
> I think I have burnt most of my arguments, especially if you don't
> answer my points about the architecture...

I thought I had. 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). 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. 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. 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.
 
> 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?

James