RE: [DM] IBM-DM-031: No need for namespace nodes

The model of namespace nodes is intrinsic to the way one of the most
complex areas of the XSLT specification is currently described. Changing
this model at this stage of the game would almost certainly introduce
serious bugs, and would have no advantages. It's not something we are
retaining only for backwards compatibility: the ability to handle
namespaces as first class objects has enabled us to provide the new
<xsl:namespace> instruction (in response to real use cases) with clean
and consistent semantics. Redesigning XSLT to use a different model is
simply not an option. If XQuery wants to use a data model without
namespace nodes, then we are going to have two different data models.

There is a precedent for modeling information in a document using hidden
objects, the way you want to model namespaces: specifically, this is how
XSLT has always handled unparsed entities. But unparsed entities are an
embarassment, because we can read them and cannot write them. This means
they are the only part of the data model where XSLT does not have
closure. XQuery does not have closure in the area of namespaces, and I'm
not prepared to take XSLT down that route.

Michael Kay

> -----Original Message-----
> From: Jonathan Robie [mailto:jwrobie@mindspring.com] 
> Sent: 12 February 2004 19:55
> To: Michael Kay
> Cc: 'Don Chamberlin'; public-qt-comments@w3.org
> Subject: Re: [DM] IBM-DM-031: No need for namespace nodes
> 
> 
> Michael Kay wrote:
> 
> >>Then perhaps the XSLT spec can describe things in terms of namespace
> >>nodes - these are equivalent descriptions, and the XSLT spec could 
> >>describe how to map between them.
> >>    
> >>
> >
> >It's very easy to have a language that doesn't make use of 
> some of the 
> >information content in the data model, such as the identity and 
> >parentage of namespace nodes. It's much harder, and less 
> desirable, for 
> >a language to supplement the data model with additional information.
> >  
> >
> But it's also undesirable for a language to represent abstract 
> declarations, such as namespace declarations, with concrete 
> nodes that 
> have identity and must be serializable, although they have no direct 
> representation in an XML document. XSLT could achieve the nice 
> properties you desire by making the same change XQuery wants to make, 
> defining the scope of namespaces without using namespace nodes - but 
> there are, of course, backwards compatibility issues.
> 
> I don't think XQuery should be burdened by these backwards 
> compatibility 
> issues.
> 
> >And don't forget that XPath supports the namespace axis too.
> >  
> >
> Yes, but it is deprecated. I suppose a compromise position 
> would be to 
> define the namespace axis in terms of the namespaces that are 
> in scope - 
> let it create "namespace nodes" to represent the namespaces 
> that are in 
> scope. This kind of crud is less objectionable in the 
> description of a 
> deprecated feature.
> 
> >And I strongly suspect that when XQuery users discover the need to 
> >create namespaces that aren't known statically (as they will), then 
> >XQuery will want this capability too.
> >  
> >
> Possibly, but I doubt very much that XQuery would do this by 
> explicitly 
> creating namespace nodes - it is much more likely that we 
> would remove 
> the restriction that the URI for a namespace declaration 
> attribute must 
> be a constant.
> 
> Jonathan
>

Received on Friday, 13 February 2004 04:38:41 UTC