Re: "XPST0008 Variable err:code has not been declared" in xsl:catch

I'm glad Gerrit spotted that, I was rather mystified.

It does raise some interesting questions about whether the XML is actually well-formed/valid. I'm never optimistic that the namespaces spec will answer questions about edge cases, but let's take a look anyway....

Section 3 (in 1.1, but 1.0 is much the same) says "The attribute's normalized value must be either an IRI reference — the namespace name identifying the namespace — or an empty string."  But famously, having said in section 3 that the value must be an IRI reference, it goes on in section 7 to say that the document is namespace-well-formed even if it isn't. (And this apparent contradiction isn't an oversight - the inconsistency was raised with the authors before publication and they defended it.)  But it does raise further questons:

(a) "normaliized value" is a reference to attribute value normalization in the XML spec. But AVN depends on the attribute's type: there's one rule for CDATA attributes and another rule for everything else. In the absence of a DTD, we must assume that it's to be treated as CDATA, and the normalization rule for CDATA replaces tabs and newlines with spaces, but leaves leading and trailing spaces intact.

(b) the way the reference to attribute normalization is written says that it's normalized for the purpose of checking its validity (though under section 7 its validity is irrelevant anyway), but it doesn't say that it's normalized for the purpose of deciding what the actual namespace URI is.

General conclusion, unsatisfactory though it may be: the leading space is part of the namespace name, this violates the rule that the namespace name must be a valid IRI, but the violation of this rule isn't an error.

What about the other specs? XSD 1.0 said that element and attribute names are QNames, and the namespace part of a QName is an anyURI, and an anyURI must be a legal URI in the sense of XLink. But they also fudged it with the famous statement in §3.2.17  " Thus in practice the above definition imposes only very modest obligations on ·minimally conforming·processors." without actually making clear what the modest obligations are. There's then another fudge: a note that says "Note:  Spaces are, in principle, allowed in the ·lexical space· of anyURI, however, their use is highly discouraged (unless they are encoded by %20)."

Faced with this total lack of clarity about what's allowed in an xs:anyURI, and hence in a QName, XSD 1.1 opened the floodgates by allowing an xs:anyURI to contain any sequence of characters. And then having syntax, like the xsi:schemaLocation attribute, where URIs containing spaces clearly wouldn't work.

So closer to home, what about XSLT/XPath/XDM - in particular, even if this namespace with a leading space is allowed by XML and XSD, could an XSLT processor throw it out as an error? Well, if it was a name constructed by XSLT, we possibly could, for example the rules for xsl:namespace say "[ERR XTDE0905] It is a dynamic error if the string value of the new namespace node is not valid in the lexical space of the datatype xs:anyURI" .- As we've seen, the rules for what's allowed in an xs:anyURI are as clear as mud, but the reference here is to the *lexical space*, and since xs:anyURI has a whitespace facet of xs:collapse, the lexical space does not include leading and trailing spaces -- even though the value space does! So xsl:namespace probably should reject a namespace name with a leading space; but that's not a license to reject it if it comes in from the XML parser.

Does the XDM spec help? Section 2.6 says: "Following the lead of [Namespaces in XML] and [Namespaces in XML 1.1], processors implementing this data model may raise an error if a namespace name is not a valid URI or IRI (depending on whether they support [Namespaces in XML] or [Namespaces in XML 1.1]), but they are not required to make any checks. "

So yes, it seems we could throw an error here if we chose. The problem then is, how far do we go? One of the few libraries to enforce rules on namespace URIs is XOM, and it's unfortunate, because it sometimes rejects namespace names that are widely used and that work with everything else. But namespaces containing whitespace aren't going to work well anywhere, and rejecting them seems reasonable.

If you've got to the end of this, sorry to spend so long on an absurdly esoteric topic.

Michael Kay
Saxonica



> On 5 Mar 2021, at 14:56, Lambert Giese <[email protected]> wrote:
> 
> True. With the leading space removed from the namespace declaration,
> everything works as expected.
> 
> Thanks!
> 
> Am 05.03.21 um 14:07 schrieb Imsieke, Gerrit, le-tex:
>> From:	Imsieke, Gerrit, le-tex ([email protected])
>> List:	net.sourceforge.lists.saxon-help
>> 
>> It will probably work if you remove the leading space in the err
>> namespace URI:
>> 
>> On 05.03.2021 12:06, Lambert Giese wrote:
>> 
>> xmlns:err=" http://www.w3.org/2005/xqt-errors
>> <http://www.w3.org/2005/xqt-errors>"
>> 
>> _______________________________________________ saxon-help mailing list
>> archived at http://saxon.markmail.org/ <http://saxon.markmail.org/>
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>> <https://lists.sourceforge.net/lists/listinfo/saxon-help>
>> 
> 
> 
> 
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 



_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help