RE: [XSLT2.0] OB04, 5.6.3 Namespace Fixup, QNames in content

Thanks for the comment. This response is provisional, subject to
confirmation by the working group.

The paragraph in question states a constraint, namely that the prefix
used in an element or attribute annotated as a QName must have a
namespace node defining that prefix.

I think it is true to say that there is no way the element or attribute
can acquire such a type annotation unless it already has such a
namespace node. A node can acquire a type annotation only as a result of
validation.

I don't think we actually say anywhere whether validation comes before
or after namespace fixup, but I also think it doesn't make any
difference to the outcome. If validation comes first, then it will fail
if there is no namespace node for the prefix of the QName. If namespace
fixup comes first, then the node will not be annotated as a QName, so
namespace fixup will not treat it specially, and validation will still
fail.

I have wondered on occasions whether we couldn't do validation and
namespace fixup as a single operation, to solve this problem. But quite
apart from the fact that we want to invoke validation as a black-box
process defined in the Schema REC, it's not clear where the namespace
URI would come from. This would only work if we retained type
information while constructing nodes (rather than the "convert to text,
then validate the text" semantics that we currently have, which are the
result of many months of agonized debate).

This does point up some weaknesses in the spec. Firstly, I think we
should clarify whether namespace fixup happens before or after
validation even if it makes no difference in the end. Logically I think
it has to happen first. This should probably be stated in section 5.6.1,
and it wouldn't do any harm to say it again in section 19.2.1.

Secondly, the paragraph you cite is fairly meaningless as stated.
Strictly speaking it's correct, in that it describes a constraint on the
data model that does actually exist; however, the implication that
namespace fixup can cause the constraint to be satisfied is wrong. So
some rephrasing is needed here.

QNames in content, of course, are an absolute pig. I have suggested to
the schema working group that they should introduce an alternative
lexical representation of QNames that retains the URI as part of the
lexical value. This would make everyone's life much easier if it were to
happen.

Thanks again,

Michael Kay

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Oliver Becker
> Sent: 06 January 2004 10:41
> To: public-qt-comments@w3.org
> Subject: [XSLT2.0] OB04, 5.6.3 Namespace Fixup, QNames in content
> 
> 
> 
> http://www.w3.org/TR/2003/WD-xslt20-20031112/#namespace-fixup
> 
> The 5th bullet talks about element or attributes that are 
> annotated with the type xs:QName. It is not clear what 
> happens in a conflict situation.
> 
> Example:
> <doc>
>   <foo xmlns:bar="urn:bar1" att1="bar:something" />
>   <foo xmlns:bar="urn:bar2" att2="bar:something" />
> </doc>
> 
> att1 and att2 should be annotated as mentioned above.
> 
> <xsl:template match="doc">
>   <xsl:copy>
>     <xsl:copy-of select="foo/@*" />
>   </xsl:copy>
> </xsl:template> 
> 
> The bar prefix is used for two different namespaces.
> Should the namespace fixup process change the value of the 
> attributes (by choosing unique prefixes)?
> 
> Regards,
> Oliver Becker
> 
> 
> /-------------------------------------------------------------------\
> |  ob|do        Dipl.Inf. Oliver Becker                             |
> |  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
> |  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
> \-------------------------------------------------------------------/
> 
>

Received on Tuesday, 6 January 2004 13:06:33 UTC