RE: [DM]: in some way a resumption of Issue-0079: String-value vs. string-value of the typed-value

It's rather late to be reopening design questions, I'm afraid: we've been
through two periods of "last call" that gave plenty of opportunity for
consultation on such things, and we're now in a "Candidate Recommendation"
phase whose purpose is to iron out any remaining small bugs before the
languages are set in concrete. We're preparing the plane for landing, not
discussing where to go on holiday.

Even for tiny changes, a request to change the language at this stage
requires a much stronger rationale than "I don't agree with XYZ" and "Why
not [do it differently]?". 

On the technical point: the rationale for the design is that it's relatively
unusual to find elements with element-only content where it makes sense to
concatenate the content of the children and treat the concatenated content
as a single string (this is far more common with mixed content). If you want
to do it, you still can, by using the string() function. 

This is part of a general programme to make the 2.0 languages more strongly
typed. The aim of introducing stronger typing into 2.0 is to catch more user
mistakes. Not everyone thinks this is a good idea, but from my point of
view, I would say that the experience of actually using the language is a
very positive one: when you get a type error, there's a reasonably high
chance that you've actually done something wrong.

If you think the wording of XPath section 2.5.2 is capable of being
misunderstood, then I suggest you raise a Bugzilla comment explaining what
it could be misunderstood to mean. See the 5th paragraph of the status
section for instructions.

Michael Kay
(personal response)


> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Klaus Bosse
> Sent: 27 April 2006 15:18
> To: public-qt-comments@w3.org
> Subject: [DM]: in some way a resumption of Issue-0079: 
> String-value vs. string-value of the typed-value
> 
> 
> In xpath-datamodel, 6.2.4 I don't agree with the typed-value 
> calculation for Element Node from a PSVI:
> 
> "...Otherwise, the element must be a complex type with 
> element-only content. The typed-value of such an element is 
> undefined. Attempting to access this property with the 
> dm:typed-value accessor always raises an error."
> 
> Why not define here the typed-value as the elements 
> string-value as an xdt:untypedAtomic, as in '6.2.3 
> Construction from an Infoset'
> (like '6.1.4 Construction from a PSVI' for Document Nodes) ? 
> The string-value is still defined in the above case.
> 
> I think this would be in line with one of Michael Kay's conclusions in
> http://lists.w3.org/Archives/Public/public-qt-comments/2002Dec/0012:
> 
> "So my own preference is that we should keep the lexical 
> value and treat the typed value as being derived from it."
> 
> 
> If 6.2.4 is not changed like that, following should be 
> changed slightly in xpath20, 2.5.2, to avoid misunderstanding:
> 
> "An implementation may store both the typed value and the 
> string value of a node, or it may store only one of these and 
> derive the other from it as needed. The string value of a 
> node must be a valid lexical representation of the typed 
> value of the node, but the node is not required to preserve 
> the string representation from the original source document. 
> For example, if the typed value of a node is the xs:integer 
> value 30, its string value might be "30" or "0030"."
> 
> 
> If 6.2.4 is not changed, can someone please explain the 
> reason for such a different typed-value handling?
> 
> 
> -----------------------------------------------------------------
> see also:
> 
> xpath20, 2.5.2:
> 
> 1.
> 
> "For text and document nodes, the typed value of the node is 
> the same as its string value, as an instance of the type 
> xdt:untypedAtomic. The string value of a document node is 
> formed by concatenating the string values of all its 
> descendant text nodes, in document order."
> 
> 4.d
> 
> "If the type annotation denotes a complex type with 
> element-only content, then the typed value of the node is 
> undefined. The fn:data function raises a type error 
> [err:FOTY0012] when applied to such a node. The string value 
> of such a node is equal to the concatenated string values of 
> all its text node descendants, in document order."
> 
> and
> 
> xslt20, 2.1:
> 
> "[Definition: The term typed value is defined in Section 5.15 
> typed-value AccessorDM. Every node except an element defined 
> in the schema with element-only content has a typed value. 
> For example, the typed value of an attribute of type 
> xs:IDREFS is a sequence of zero or more xs:IDREF values.]"
> 
> --------------------------------------------------------------
> ---------------
> 
> Regards
> Klaus Bosse
> 
> 
>

Received on Thursday, 27 April 2006 15:02:25 UTC