[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xsl-list
Subject:    Re: [xsl] Excluding Namespaces from the Result Tree
From:       "Michael Kay mike () saxonica ! com" <xsl-list-service () lists ! mulberrytech ! com>
Date:       2015-06-30 11:20:29
Message-ID: 20150630071956.34755 () lists ! mulberrytech ! com
[Download RAW message or body]


> 
> I do understand that for XSLT element or attribute values are just plain
> values/strings although they might be qualified names. Would a
> schema-aware processor solve this problem? I have never used one…
> 

Turns out that schema-awareness doesn’t really help much here, apart from giving \
better diagnostics when things are wrong.

Firstly, not all elements/attributes that have prefixes-in-content are marked in the \
schema as QName type. For example, the attribute might hold an XPath expression, for \
which there is no way of saying in XSD “this is a string that may contain namespace \
prefixes”.

Secondly, we found it impossible to make namespace fixup conditional on validation, \
that is, to say that namespace fixup should generate namespace nodes for prefixes \
that are used in a node of type xs:QName, This is basically because we don’t know \
it’s an xs:QName until we validate, and we need the namespace bindings to be in place \
before we validate, otherwise validation will fail. The only way to do it would be to \
somehow inject namespace fixup into the middle of the XSD-defined validation process, \
which was not something we were prepared to contemplate.

Michael Kay
Saxonica
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/651070
or by email: xsl-list-unsub@lists.mulberrytech.com
--~--


[prev in list] [next in list] [prev in thread] [next in thread]