- From: Michael Rys <mrys@microsoft.com>
- Date: Thu, 12 Feb 2004 12:14:08 -0800
- To: <jwrobie@mindspring.com>
- Cc: "Michael Kay" <mhk@mhk.me.uk>, "Jonathan Robie" <jonathan.robie@datadirect.com>, "XML Query Comments" <public-qt-comments@w3.org>
See below. > -----Original Message----- > From: Jonathan Robie [mailto:jwrobie@mindspring.com] > Sent: Thursday, February 12, 2004 11:09 AM > To: Michael Rys > Cc: Michael Kay; Jonathan Robie; XML Query Comments > Subject: Re: [DM] Typed value for elements > > Michael Rys wrote: > > >>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... > > > > > We may be talking past each other. With the current definition of > dm:typed-value(), the result of the first query depends on whether the > "head" element is untyped. I don't think that's good. I think that the > first query should raise an error regardless of the schema or lack > thereof. [Michael Rys] I disagree. I think it should work (assuming dynamic typing) in either case. I agree that there is a complexity with typed complex content data with respect to differentiating mixed and non-mixed content and since you can derive non-mixed from mixed content, you will have to statically disallow both. However, dm:typed-value() is the basis of fn:data() and thus atomization. As such I think it is really related to value-of and all functions that except an atomic string (or other atomic value, but string is the most common usecase). > Some people believe that it would be better for the typed value to be > computed from the string value, including all descendants. Others > believe that the typed value accessor should always raise an error if > the element has children (if dynamic evaluation is being performed) or > the element's definition allows children (if static analysis is being > performed). Either decision provides a consistent model. Let's bite the > bullet and make a clean design decision. For my money, anything that > computes the string value from descendant elements should require a > cast. For my money, the requirements for xslt:value-of, which creates a > text node, are different from the requirements for dm:typed-value(), > which creates a typed value, so we should not let xslt:value-of drive > the definition of dm:typed-value(). > > What we now have is a compromise based on a particular set of examples > that we had been considering, not a clean design. The current definition > of dm:typed-value() is an obvious instance of design by committee, and > should be cleaned up. > > Jonathan
Received on Thursday, 12 February 2004 15:14:07 UTC