RE: Should fn:string() and xs:string() be synonyms?

We have tried that and have not found one that does not break either
backwards-compatibility or general casting alignment.

I would rather spend time on more important issues than trying to square
the circle...

Best regards
Michael (speaking from himself)

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Jonathan Robie
> Sent: Tuesday, February 10, 2004 4:03 PM
> To: Michael Kay
> Cc: 'Jonathan Robie'; 'XML Query Comments'
> Subject: Re: Should fn:string() and xs:string() be synonyms?
> 
> 
> Michael Kay wrote:
> 
> >>We currently have a function called fn:string() and a
> >>constructor called xs:string(), which both create strings. There
> >>is some justification for having both. xs:string is a constructor
> >>for a built-in type, and all built-in types have associated
> >>constructors. fn:string() is a widely used function in XPath
> >>1.0, so it is difficult to remove it at this point.
> >>
> >>But they are defined differently. fn:string() uses the
> >>string value, whereas xs:string() atomizes the node and casts
> >>the result to a string. These two definitions give subtly
> >>different results. Could one be made a synonym for the other,
> >>to avoid confusion?
> >>
> >>
> >
> >What would you propose as the common definition?
> >
> >
> Well, that depends....
> 
> >I think this depends on the resolution of the data model issue
whereby
> >the string-value of a node is currently underspecified, for example
it
> >isn't clear whether the string value of a decimal attribute
containing
> >"4.00" is "4.00" or "4". Assuming it's "4.00", then the fn:string()
> >function is currently the only way of getting the string value of the
> >node; but casting to a string should definitely give the canonical
> >representation of the number.
> >
> >
> And that's one of the big things it depends on. I think we should seek
a
> common definition that suits both purposes, and that seems possible.
> 
> Jonathan

Received on Tuesday, 10 February 2004 19:31:05 UTC