Re: [DTB] ACTION 704 completed

Jos de Bruijn wrote:
>>> Re: the first editor's note in section 3.1.1
>>> I believe the predicates should depend on a specific domain, and should
>>> be undefined if it is not the case that both arguments are in the same
>>> value space.
>>> This only becomes an issue, of course, if we decide to adopt these
>>> predicates, which is not something I support.
>>> <snip/>
>>>> 1) As noted in the editor's note, it seems to me that
>>>>  pred:literal-equal
>>>> is redundant. If that is untrue, let me know.
>>> this is not true (at least it should not be).  Equality in XML schema is
>>> not the same as identity.
>>>> Now here goes an example for the problem case, assuming disjoint
>>>> datatypes decimal and double (please confirm),:
>>>>   pred:numeric-equals("1"^^xs:double , "1"^^xs:decimal) = t
>>>>   pred:literal-equals("1"^^xs:double , "1"^^xs:decimal) = f
>>> literal-equals should behave the same as numeric-equals on numbers.  It
>>> seems to me that you made a mistake in the definition.
>> I tried to write down what we discussed, to get a better understanding
>> ofg what we want... it was/is not clear to me what you mean by "mistake"
>> at this point. If you think that literal-equals should do promotion,
>> that is one point of view, there might be others.
> Okay, then we have different ideas about the discussion was about.  I
> thought the discussion was about replacing the individual comparison
> operators with one comparison operator for all datatypes.

the discussion had two parts:

i) defining generic comparison predicates
ii) deciding whether these can replace the specific ones

as for the latter, numeric-equals is an obstacle at the moment.

> It seems that now that you are proposing to add new comparison operators
> that are in fact quite different from the individual comparison
> operators we currently have.  Are you proposing to remove the individual
> comparison operators or do you want to keep them?

I personally am not decided yet on this issue, I think we need to 
discuss it. If we want replacement (which indeed I was hoping we could 

I see three options:

- we keep both the generic and the specific equalities.

- we remove the specific comparison predicates and accept that we don't 
cover the specific functionality of numeric-equal that includes 
promotion and enable this "feature" only via explicit casts.

- we remove the specific comparison predicates and change the definition
of literal-equals to comprise numeric-equal... I don't like this, 
because it may hamper extesibility of the definition of literal-equals 
to other datatypes.


Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
email:  url:

Received on Wednesday, 11 February 2009 11:58:01 UTC