This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1235 - [XSLT] Namespace fixup for QName-valued content is unduly onerous
Summary: [XSLT] Namespace fixup for QName-valued content is unduly onerous
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-11 08:21 UTC by Michael Kay
Modified: 2005-07-14 22:33 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2005-04-11 08:21:25 UTC
[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
</x>

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
</x>

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
generated. 

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:variable>

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

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.
Comment 1 Michael Kay 2005-04-28 17:54:03 UTC
The WG agreed to make this change, with some reservations from MSMQ
Comment 2 Michael Kay 2005-05-04 12:15:16 UTC
These changes have now been applied in editor's draft Y.
Comment 3 Michael Kay 2005-05-18 17:40:04 UTC
In joint discussion with the XQuery WG it seems that XQuery prefers to retain
the "namespace fixup" status quo. Therefore XSL WG will reconsider the decision.
Comment 4 Michael Kay 2005-06-14 13:19:27 UTC
At the XSL WG telcon on 9 Jun 2005, the WG decided that we didn't want to
perform namespace fixup for this case: but rather than making an outright ban on
the combination of validation=preserve with copy-namespaces=no, we would raise a
dynamic error if this leads to the data becoming invalid - that is, if it causes
typed QName values to be copied without their namespaces being copied.

The specific change is to replace the text of the new error 0950:

<old>
It is a static error if the copy-namespaces attribute of hte xsl:copy or
xsl:copy-of instruction has the value no when its explicit or implicit
validation property has the value preserve. This is because the validity of the
content may depend on the namespace context.
</old>

<old>
It is a type error if the copy-namespaces attribute of the xsl:copy-of
instruction has the value no, and its explicit or implicit validation property
has the value preserve, and the content of a node being copied includes
namespace-sensitive content, that is the typed value of the node contains an
value of type xs:QName or xs:NOTATION or a type derived or constructed
therefrom. This is because the validity of the content may depend on the
namespace context.
</old>

I propose also to merge this with error 0955, which describes a very similar
error condition for attribute nodes.

Michael Kay
Comment 5 Michael Kay 2005-07-14 22:33:19 UTC
In subsequent discussions, the XSL and XQuery groups decided that for both
specs, it would be an error to copy type annotations without copying namespaces
only in the case where namespace-sensitive content is actually present. This
change has been applied to the spec.