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.

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 14:11:13 UTC