W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2005

[Bug 1235] New: [XSLT] Namespace fixup for QName-valued content is unduly onerous

From: <bugzilla@wiggum.w3.org>
Date: Mon, 11 Apr 2005 08:21:26 +0000
To: public-qt-comments@w3.org
Message-Id: <E1DKuAg-0007P0-10@wiggum.w3.org>


           Summary: [XSLT] Namespace fixup for QName-valued content is
                    unduly onerous
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.0
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org

[XSLT] Namespace fixup for QName-valued content is unduly onerous

We currently require a namespace processor to perform namespace fixup (that is,
to generate any required namespace nodes) in respect of qualified names (QNames
or NOTATIONs) appearing within the value of an element or its attributes. I
believe this requirement is unnecessarily onerous.

Note that when creating new content, the user is required to create any
necessary namespaces "by hand". The system can't help with this because
namespace fixup is done before validation, and before validation there are no
type annotations to identify the content as being QName-valued. Namespace fixup
applies only where the content is already annotated as a QName at construction
time, which can only happen when copying an existing element or attribute node.

In the case of element content, the only scenario where namespace fixup has to
do anything (I believe) is with <xsl:copy-of copy-namespaces="no"> For example,
consider the source fragment, in which the element x is annotated with a simple
type list-of-qnames:

<x xmlns:p="p.uri" xmlns:q="q.uri" xmlns:r="r.uri">
  <!-- a comment -->
  <? a processing instruction ?>
  p:local r:local

If this is copied using

<xsl:copy-of select="x" copy-namespaces="no" validation="preserve"/>

then the expected output is:

<x xmlns:p="p.uri" xmlns:r="r.uri">
  <!-- a comment -->
  <? a processing instruction ?>
  p:local r:local

that is, namespace q.uri has been dropped because it is not used in the content.
Note that this means that the copy operation (unlike all other copy operations)
cannot be streamed: the content must be known before the namespaces can be

I propose that instead we should prohibit this situation. Specifically, we
should not allow copy-namespaces="no" to be used with validation="preserve".

The problem with QName-valued attributes is slightly different. An example here is:

<xsl:variable name="source" xmlns:xsi="http://.../XMLSchema-instance">
  <e xsi:type="xs:decimal" validation="strict">93.7</e>

  <xsl:copy-of select="$attribute" validation="preserve"/>

The current rules require that namespace fixup in effect copies not only the
attribute node, but also the namespace nodes for the xsi and xs namespaces. This
in effect means that the processor has to use a value-based representation for
the attribute node being copied, so that it can retain the namespace
information: either that, ro it must combine the copy with the namespace fixup
into a single operation. This is feasible, but it's not clear that the added
complexity is justified.
Received on Monday, 11 April 2005 08:21:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:23 UTC