- From: Michael Kay <mhk@mhk.me.uk>
- Date: Fri, 13 Feb 2004 12:27:51 -0000
- To: "'Jonathan Robie'" <jonathan.robie@datadirect.com>, "'Michael Rys'" <mrys@microsoft.com>
- Cc: "'XML Query Comments'" <public-qt-comments@w3.org>
> Now I want to do the following query: > > let $people := doc('people.xml') > return contains($people, "Rys") > > When the query attempts to cast $people to a string, it will try to > atomize the element using dm:typed-value(), and the following > rule applies: > > If the node has a complex type with complex content, raises a > type error, which may be handled by the host language. > > We should see if there are other functions/operators that > have this same problem. > All string functions potentially have this problem, there is no reason to special-case contains. For example, it applies just as much to concat(). How about the following as a way forward: New rule: the typed value of an element node whose type is a complex type with complex content (regardless whether this is mixed content or element only content) is a string consisting of the concatenation of the descendant text nodes of the element, in document order. This is typed as xs:string, unless the element has type xdt:untyped, it which case it is typed as xdt:untypedAtomic. This means that elements with children can be used in any context that expects a string, but not in contexts that expect (say) a number or a date. Consider the case where $a in the element <a><b>123</b></a> and <a> is defined with element-only content. We already have a backwards incompatibility that $a + 1 works in XPath 1.0 but not in 2.0 (once you apply a schema). This rule extends the incompatibility to mixed content, (but not to cases where there is no schema). We trade against that the fact that under the current rules, <a> cannot be used in a string context, whereas under the new rule it can. One advantage of this rule is that it's a good thing if the basic primitives of the language such as EBV and atomization are error-free operations. The more errors we raise, the more problems we have with different optimizations producing different results. If there is a reasonable interpretation of a construct, we should apply it; we should only raise errors in cases of things that no right-thinking person would do deliberately. Michael Kay
Received on Friday, 13 February 2004 07:27:14 UTC