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-to-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 16:46:21 UTC