RE: hexBinary & base64Binary comparisons

I think you've misread the text. It is saying that the semantics of

A cast as B

are identical to the semantics of

B(A)

and the only difference is the syntax.

Michael Kay
 

> -----Original Message-----
> From: w3c-xsl-wg-request@w3.org 
> [mailto:w3c-xsl-wg-request@w3.org] On Behalf Of Jeremy Carroll
> Sent: 05 October 2004 17:46
> To: Ashok Malhotra
> Cc: Michael Kay; w3c-xml-query-wg@w3.org; w3c-xsl-wg@w3.org; 
> SWBPD list
> Subject: Re: hexBinary & base64Binary comparisons
> 
> 
> 
> 'cast and then compare' can be done fairly frequently, even 
> when values 
> are somehow 'different' e.g. strings and decimals
> 
> http://www.w3.org/TR/xpath-functions/#casting-from-primitive-t
> o-primitive
> 
> shows that the cast can be done one way, and maybe the other. I find 
> this in section 17 Casting, a little confusing:
> [[
> Constructor functions and cast expressions accept an expression and 
> return a value of a given type. They both convert a source 
> value, SV, of 
> a source type, ST, to a target value, TV, of the given target 
> type, TT, 
> with identical semantics and different syntax.
> ]]
> 
> since, at least on my reading, the semantics of a string and 
> a decimal 
> are different, and hence cannot be 'identical', whereas at 
> least in some 
> of the cases, the semantics is plausibly 'identical' (e.g. the binary 
> encoding datatypes).
> 
> So I tend to a reading in which 'cast and then compare' does 
> not entail 
> 'identical' semantics, but that XPath eq both not raising an 
> exception 
> and returning true, as indicating identical semantics (modulo 
> rounding 
> errors)
> 
> (I am sorry that this may seem somewhat pedantic. Unfortunately it is 
> easy to construct RDF and/or OWL test cases where the 
> behaviour depends 
> critically on these somewhat academic distinctions!)
> 
> Jeremy
> 
> 
> 
> Ashok Malhotra wrote:
> > We discussed this and instead of allowing comparison operators
> > the WGs decided to allow casting from one type to another.
> > So, you have cast and then compare. 
> > 
> > All the best, Ashok
> > 
> > 
> > -----Original Message-----
> > From: w3c-xml-query-wg-request@w3.org
> > [mailto:w3c-xml-query-wg-request@w3.org]On Behalf Of Michael Kay
> > Sent: Tuesday, October 05, 2004 5:46 AM
> > To: 'Jeremy Carroll'; 'Ashok Malhotra'
> > Cc: w3c-xml-query-wg@w3.org; w3c-xsl-wg@w3.org; 'SWBPD list'
> > Subject: RE: Request for help with semantics of XML Schema Datatypes
> > 
> > 
> > 
> > 
> >>Another one of the surprises for me was that hexEncodedBinary and 
> >>base64EncodedBinary always compare not equal, even if the 
> binary that 
> >>has been encoded is the same. Is this still being worked on? Or has 
> >>there been a WG decision on that?
> > 
> > 
> > They don't "compare not equal", they are non-comparable: (b 
> eq h) is an
> > error. 
> > 
> > No logic to it, it's just that no-one has found the time or 
> energy to do any
> > work on these two types.
> > 
> > Michael Kay
> > 
> > 
> > 
> 
> 
>

Received on Tuesday, 5 October 2004 17:18:31 UTC