- From: Michael Rys <mrys@microsoft.com>
- Date: Thu, 12 Feb 2004 11:56:00 -0800
- To: <jwrobie@mindspring.com>, "Michael Kay" <mhk@mhk.me.uk>
- Cc: "Jonathan Robie" <jonathan.robie@datadirect.com>, "XML Query Comments" <public-qt-comments@w3.org>
Contains expects a string typed value. The semantic rules of atomization will employ fn:data()/dm:typed-value(). Even for fn:contains(). Your proposal is going to either remove useful functionality or add additional complexity in the atomization process. Neither of which I am in favor of. Best regards Michael > -----Original Message----- > From: public-qt-comments-request@w3.org [mailto:public-qt-comments- > request@w3.org] On Behalf Of Jonathan Robie > Sent: Thursday, February 12, 2004 11:43 AM > To: Michael Kay > Cc: 'Jonathan Robie'; 'XML Query Comments' > Subject: Re: [DM] Typed value for elements > > > Michael Kay wrote: > > >>>The expression: > >>> > >>> <xsl:value-of select="div/head"/> > >>> > >>>would break. > >>> > >>> > >>This is the kind of example I have seen most frequently in this > >>discussion - examples where formatting occurs in a string, and either > >>string comparisons or value-of are done. > >> > >> > > > >Precisely. That's what mixed content is all about. The text is the > >information, the markup is incidental. It's not just <xsl:value-of>, > >it's any operation that cares more about the text than about the markup. > >The expression contains(head, "H2O") should indeed return true, because > >the markup is mere annotation. > > > > > Yes ... but the purpose of xslt:value-of is to create a text node, and > we agree that it should not raise an error in the above case. I > suggested that the requirements of xslt:value-of are different than > those for dm:typed-value(), and there are certainly other operations > whose requirements are different than those for dm:typed-value(). One of > these is contains(), which is clearly a text-oriented function that > should be defined on the string value, not the typed value. In fact, > this function's arguments are strings: > > fn:contains($arg1 as xs:string?, $arg2 as xs:string?) as xs:boolean > > fn:contains($arg1 as xs:string?, > $arg2 as xs:string?, > $collation as xs:string) as xs:boolean > > So with or without the change I don't see the problem with contains. > > Consider your own words: "it's any operation that cares more about the > text than about the markup". When an operation wants the text rather > than the typed value, it should be defined accordingly. Two good > examples of such operators are xslt:value-of and fn:contains. My > proposal would require a change in the definition of xslt:value-of, a > change that would make it more compatible with XSLT 1.0. My proposal > would require no change to fn:contains. > > Are there other operators you are concerned about? > > >Certainly such constructs shouldn't suddenly cause stylesheets to fail > >because someone discovers that the DTD allows markup in a heading and > >decides to exploit the capability. > > > > > I'm not arguing that stylesheets should fail in these cases, I am > arguing that text-oriented operators like xslt:value-of (which creates a > text node) and fn:contains (which operates on strings) are different > from operators that require typed values. I think we agree on how > xslt:value-of and fn:contains should operate, at least in general. > > >The only other approach I could think of would be that atomization is > >sensitive to the required type, and gives you the string value if the > >required type is string. But this is piling up the complexities, in my > >view unnecessarily. > > > > > I agree that this would be a bad approach. > > Jonathan
Received on Thursday, 12 February 2004 14:56:33 UTC