- From: Michael Rys <mrys@microsoft.com>
- Date: Thu, 12 Feb 2004 11:03:47 -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>
> let $h := <head>The properties of H<sub>2</sub>O</head> > return $h = "The properties of H2O" > > I do think that the following should return true: > > let $h := <head>The properties of H2O</head> > return $h = "The properties of H2O" > > And I think that the two cases should be distinguished. I disagree with you on that the two queries above should behave differently on untyped documents. There are other ways to make them distinguish... 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 10:53 AM > To: Michael Kay > Cc: 'Jonathan Robie'; 'XML Query Comments' > Subject: Re: [DM] Typed value for elements > > > Michael Kay wrote: > > >>It would be much simpler and cleaner to say that > >>dm:typed-value() returns an error for any node with child > >>elements. This is incompatible with the behavior of XPath > >>1.0, but so is the current behavior for elements of known > >>complex type. > >> > >> > >> > > > >This would mean that given: > > > > <div> > > <head>The properties of H<sub>2</sub>O</head> > > </div> > > > >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. > > It's not clear to me that value-of, which exists for the purpose of > creating a text node, should drive the semantics of dm:typed-value(), > which exists for the purpose of deriving typed values. You could, for > instance, say that value-of implicitly uses string() as part of its > definition: > > <xsl:value-of select="string(div/head)"/> > > This seems preferable to moving the string value into the definition of > typed value, and works regardless of the definition of the element, so > it gives you better compatibility with XSLT 1.0. In XQuery, I do not > think that the following should silently return true: > > let $h := <head>The properties of H<sub>2</sub>O</head> > return $h = "The properties of H2O" > > I do think that the following should return true: > > let $h := <head>The properties of H2O</head> > return $h = "The properties of H2O" > > And I think that the two cases should be distinguished. > > >What's more, it would work on the first 200 documents that you test it > >against, if your testing is sufficiently thorough, and it would then > >break on the 201st. > > > >Not acceptable! > > > > > But I don't see how the current definition fixes this problem. Consider > the following expression: > > for $i in document('201.xml')//foo > return <twice>{ $i * 2 }</twice> > > With either definition, you either get a result or an error depending on > the values of individual 'foo' elements. For instance you would get an > error if the value of "foo" is: > > <foo>Hi, Mom!</foo> > > You would also get an error if the value of "foo" is: > > <foo><asdf>123</asdf></foo> > > Do you really believe that it is not acceptable for the behavior of an > operation to depend on the value of an operand? Of course, if you have a > schema that defines the 'foo' element, you can know what it can contain, > but arbitrary operations on unknown elements can raise errors. Defining > value-of in terms of string value may well be desirable for XSLT. But I > don't think that's the right definition for the typed value in XPath. > > >Breaking in the case of element-only content (as currently defined) is > >much more acceptable because (a) it only breaks if you add a schema, (b) > >this kind of construct with element-only content is unusual, whereas > >with mixed content it is very common, and (c) it would break on the > >first document you tested it against. > > > > > But I still don't think it's what you want for value-of in XSLT, is it? > I think value-of should try to be compatible with XSLT 1.0, for this > case as well as the others. But value-of and typed-value have different > design criteria. > > Jonathan
Received on Thursday, 12 February 2004 14:03:48 UTC