RE: XML Query WG Feedback on Sept WD of Namespaces in XML 1.1

This is a very comprehensive reply to our feedback but your message
gives the XML Query WG about one week to arrange for a possible reply.
I will try to achieve this by placing this on the XQuery distributed
meeting agenda for Dec 4 but I cannot guarantee that we will be able to
decide if we consent/object in this time period.

/paulc
Chair, XML Query WG

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 
<mailto:pcotton@microsoft.com> 


> -----Original Message-----
> From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk]
> Sent: Thursday, November 28, 2002 1:34 PM
> To: w3c-xml-query-wg@w3.org
> Cc: xml-names-editor@w3.org
> Subject: XML Query WG Feedback on Sept WD of Namespaces in XML 1.1
> 
> 
> This is a formal response from the XML Core WG to your comments on the
> Namespaces in XML 1.1 last call working draft.
> 
> If we haven't heard from you by the end of Monday December 9th, we
> will assume for the purposes of our planned CR request that you have
> no objection to our resolution.
> 
> Commenter email address: w3c-xml-query-wg@w3.org
> 
> > Subject: XML Query WG Feedback on Sept WD of Namespaces in XML 1.1
> >
> >[...]
> 
> > 1. We think it is useful to be able to use empty attribute values to
> > undeclare namespaces. Some Working Group members, however, are
> > concerned that the costs to the user community of introducing a new
> > version exceed the benefits obtained from this change.
> 
> Summary: rejected
> 
> It may of course turn out that the costs are too high, but if so
> we will find out during the CR period.
> 
> > 2. As the world becomes more open to the world's languages, moving
to
> > IRIs is clearly the right thing to do. The specification does not
> > state whether processors are required to reject invalid IRIs, and it
> > should clarify this.
> >
> > Note: XML 1.0 processors normally do not check for URI validity for
> > namespace URIs.
> 
> Summary: accepted
> 
> We now state explicitly that processors are not required to check.
> We reached this decision after feedback from Martin Duerst.
> 
> > 3. In the "Conformance of Documents" section, it is very good indeed
> > that colons can no longer be part of a local name, which has always
> > been confusing.
> 
> Note that the changes to that section are an erratum to 1.0, as well
> as appearing in 1.1.
> 
> > 4. We dislike the following note:
> >
> >      Though they are not themselves reserved, it is inadvisable to
use
> >      prefixed names whose LocalPart begins with the letters x, m, l,
as
> >      these names would be reserved if used without a prefix.
> >
> > It does not clearly state a concern, and the term "inadvisable" is
not
> > clearly defined anywhere - does that mean vendors have to support
such
> > names, issue warnings, or may they decide not to support them? The
use
> of
> > adjectives without well defined meaning does not lead to an
> interoperable
> > world.
> 
> Summary: rejected
> 
> We believe that "inadvisable" carries the intended, non-normative,
> meaning, and that the statement that they are not reserved makes clear
> their normative status.  Processors must accept them (though they can
> of course issue a warning if they wish).
> 
> > 5. The namespace spec should say how namespace declarations should
map
> > onto the Infoset. It should distinguish the syntactic form from the
> > information content in sentences like the following:
> >
> >[...]
> 
> Summary: accepted in part
> 
> The Infoset spec is layered on top of XML 1.x and Namespaces 1.x, and
> namespace processing occurs before (and as part of) the construction
> of an Infoset.  The Namespace spec cannot therefore use Infoset terms
> for its input, and the description of the Infoset properties belongs
> in the Infoset spec.  However, we now defined the terms "namespace
> name" and "local name" consistently with the Infoset, XPath, and XML
> Schemas, which we hope goes some way to resolving your concern.
> 
> > The ability to undeclare namespaces creates the possibility of
> > creating InfoSets that cannot be serialized as XML 1.0.
> 
> This is true.  But note that
> 
>  - other aspects of XML 1.1 also have this effect (new name characters
>    in particular)
> 
>  - this situation already exists in the XPath data model, and the
>    solution is the same: these infosets can be serialized inaccurately
>    in the sense that there will be extra namespace bindings.  Adding
>    namespace prefix undeclaring will allow these more accurate
>    serialization of XSLT output as XML 1.1.
> 
> > We need to
> > understand how the InfoSet will tackle this problem: will there be
> > different InfoSets for XML 1.0 and XML 1.1, or will there be a
single
> > InfoSet with rules for mapping it to both XML 1.0 and 1.1?
> 
> We expect to issue a minor update to the Infoset spec, mentioning
> prefix undeclaring.  There will not be two Infosets, but as you
> say some Infosets will not be accurately serializable as XML 1.1.
> 
> > For the
> > XPath/XQuery data model, there will clearly be an expectation that
> > XSLT can be used to convert from 1.0 to 1.1 or vice versa, and
> > therefore the XPath data model will need to support the union of the
> > two. Unless the Infoset does the same, it will become difficult to
> > define the XPath model in terms of the Infoset.
> 
> As mentioned above, the XPath data model already has the problem of
> documents that can't be serialized accurately because of namespaces
> that should not be in scope.  Prefix undeclaring brings the Infoset
> into line with XPath, and solves (in XML 1.1) the problem of
> unserializable XPath data models.
> 
> To be concrete, consider the following stylesheet:
> 
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> 
> <xsl:template match="*">
>  <xsl:copy>
>   <xsl:apply-templates/>
>  </xsl:copy>
> </xsl:template>
> 
> <xsl:template match="a">
>  <xsl:copy>
>   <xsl:apply-templates select="../b"/>
>  </xsl:copy>
> </xsl:template>
> 
> </xsl:stylesheet>
> 
> applied to this document:
> 
> <foo>
>  <a xmlns:p="http://example.com"/>
>  <b/>
> </foo>
> 
> (The stylesheet copies all b siblings into each a element.)
> 
> The result is
> 
> <foo>
>  <a xmlns:p="http://example.com"><b/></a>
>  <b/>
> </foo>
> 
> which is inaccurate because the <b> child of <a> has the p prefix in
> scope.  With Namespaces 1.1 it would be possible to output
> 
> <?xml version="1.1"?>
> <foo>
>  <a xmlns:p="http://example.com"><b xmlns:p=""/></a>
>  <b/>
> </foo>
> 
> which is an accurate representation of the XSLT result tree.
> 
> > 6. The namespace specification either needs to fix namespaces to
work
> > properly with DTDs, or state clearly that they do not.
> 
> Summary: accepted
> 
> We have added a statement about the problems of using DTDs with
> namespaces.
> 
> > 7. The specification should say what it means for a parser to
conform
> > to the namespace spec - it currently says only what it means for a
> > document to conform.
> 
> Summary: accepted
> 
> We have added a processor conformance section.
> 
> -- Richard Tobin, Namespaces 1.1 editor

Received on Thursday, 28 November 2002 17:29:39 UTC