RE: [DM] Typed value for elements

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