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 13:34:19 UTC