The relevant statement in the spec is XQuery 3.7.1.1 clause 5:
"If the attribute name is xml:id, then xml:id processing is performed as
defined in [XML ID]. This ensures that the attribute has the type xs:ID
and that its value is properly normalized. If an error is encountered
during xml:id processing, an implementation MAY raise a dynamic error
[err:XQDY0091]."
So yes, the effect is to some extent implementation-defined.
Saxon never raises XQDY0091. It does apply normalize-space() to the
value, but unless you are validating the result tree, it doesn't
complain if the value isn't a valid NCName. I'm not sure why I made this
decision; it's conformant with the spec, but my feeling today would be
that validating the value (and reporting an error) would be preferable.
Michael Kay
Saxonica
On 08/06/2012 18:55, David Sewell wrote:
Working within MarkLogic, I just got bitten by a server error caused
by lexically invalid @xml:id in the input data. Boiled down, this was
the offending query:
let $in := <input xml:id="-ptr"/>
return element out {
attribute id { $in/@xml:id }
}
MarkLogic complains: XDMP-LEXVAL: xs:ID("-ptr") -- Invalid lexical
value "-ptr"
So it is obviously trying to cast '-ptr' as xs:ID and failing. But I
notice that Saxon doesn't throw an error in this case. Either processor
is happy if I wrap string() around $in/@xml:id.
I'm just wondering if this is an implementation-dependent matter, or
what the specs might say about such a case.
David S.
_______________________________________________
[email protected]
http://x-query.com/mailman/listinfo/talk
