RE: Questions about "equal" fundamental facet

Sandy:
> So the concept is to count the number of digits on the canonical 
> representation, right? I can certainly live with this. But I
originally 
> thought that only significant digits count, and it'd be 0 for both
faction > and total digits.

The value we call "zero" is an abstract concept.  There are several
lexical forms allowed for it: 0, 0.0, 0.00 and so on.  We need to pick
one to answer 
the question you asked.  I picked the canonical form but there are
clearly
other possible answers.  I wanted to get this thread started to solicit
other opinions.

All the best, Ashok 
===========================================================


-----Original Message-----
From: sandygao@ca.ibm.com [mailto:sandygao@ca.ibm.com] 
Sent: Thursday, April 25, 2002 11:00 AM
To: Ashok Malhotra
Cc: Biron,Paul V; www-xml-schema-comments@w3.org
Subject: RE: Questions about "equal" fundamental facet

> 1. what are the values of totalDigits/fractionDigits for decimal
"0.00"?
> [AM] 2/1 corresponding to 0.0

So the concept is to count the number of digits on the canonical
representation, right? I can certainly live with this. But I originally
thought that only significant digits count, and it'd be 0 for both
faction
and total digits.

> 2. Whether international decimal characters that are out of the range
> #x30~#x39 (#x660, for example) are allowed in date time types?
> [AM] No.  We should allow only the characters we allow for decimal.

This is what I expected. Just wanted to make sure. Thanks.

> Clearly, this is important for operations on datatypes but why is this
> important for Schema ?  Schema uses equality only for min/max
> inclusive/exclusive and enumerated values.

First of all, "equality" is referenced by two other places in the
structure
spec: identity constraint validation (3.11.1) and particle derivation
(3.9.6, Elt -- NameAndTypeOK). Of course, these two places fit into the
current "equality" definition, but users might expect float(1.0) and
double(1.0) to be equal for identity constraint validation.

Another place where it should be referenced is in complex type
derivation
(restriction) (3.4.6).
"2.1.3.2 R's *effective value constraint* is fixed with the same string
as
B's."
Shouldn't it be "with the same value as B's"? Reasons:
1. value constraint is a pair of (default|fixed) and an (actual) value.
No
string here.
2. String comparison implies 1.0 != 1.00. I don't think this is the
intention. Similar constraint for elements (NameAndTypeOK mentioned
above)
compares the values, not strings.

And more importantly, schema datatypes are considered (by many users)
the
standard XML type system, so people want to make use of it as much as
possible. Xerces has received many requests to expose the implementation
of
schema datatypes, how strings are validated, how actually values are
represented, and how to get the actual values of elements and attributes
(instead of just a normalized value in PSVI). So people definitely want
to
use the schema types/values, and equality (and order) comparisons seem
to
be so natural in such use.

So schema datatypes functioning as a powerful type system, instead of
just
for schema validity checking, would be really beneficial.

Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com



 

                    "Ashok

                    Malhotra"            To:     Sandy
Gao/Toronto/IBM@IBMCA                                       
                    <ashokma@micro       cc:
<www-xml-schema-comments@w3.org>, "Biron,Paul V"                  
                    soft.com>             <Paul.V.Biron@kp.org>

                                         Subject:     RE: Questions
about "equal" fundamental facet                
                    04/25/2002

                    11:53 AM

                    Please respond

                    to "Ashok

                    Malhotra"

 

 




Sandy, you asked two questions.  I'm not definite about the answers but
I'm
putting out some answers to start discussion.

1. what are the values of totalDigits/fractionDigits for decimal "0.00"?

[AM] 2/1 corresponding to 0.0

2. Whether international decimal characters that are out of the range
#x30~#x39 (#x660, for example) are allowed in date time types?
[AM] No.  We should allow only the characters we allow for decimal.

On your question about equality, I answered the general question.  You
make that there are special cases where 2 primitive types share a value
space and
in such cases we could define equality across the shared spaces.

Clearly, this is important for operations on datatypes but why is this
important for Schema ?  Schema uses equality only for min/max
inclusive/exclusive and enumerated values.

All the best, Ashok
===========================================================


-----Original Message-----
From: sandygao@ca.ibm.com [mailto:sandygao@ca.ibm.com]
Sent: Thursday, April 25, 2002 8:37 AM
To: Ashok Malhotra
Cc: www-xml-schema-comments@w3.org
Subject: RE: Questions about "equal" fundamental facet

Hi Ashok. Thanks for your reply.

> [AM] I don't know how to tell if two value spaces are subsets of some
primitive value space.  I only know such a relation exists for types
derived by restriction.

There are 19 primitive types. If hexBinary and base64Binary share the
same
value space (this seems to be true according to how their value spaces
are
defined); QName and NOTATION share the same value space; float has a
value
space that's a subset of that of double, then we have 16 primitive value
spaces. We need another one for list values: list of a union of the
other
16 primitive value spaces. So we have totally 17. Each value space
represents its values in a distinct way, that is, a different Java class
if
it's represented in Java.

Now given two values, no matter how they were generated, by which types,
their equality can be checked independent of the types:

The two values are equal if and only if they both belong to the same
primitive value space (call it PVS) (that is, both are list values, or
both
are non-list values, and belong to the same non-list primitive value
space), and the appropriate case among the following is true:
1.1 the PVS is not the list value space, and the two values represent
the
same value in this PVS.
1.2 the PVS is a the list value space, and the two values have the same
length, and all their item values at matching index are equal.

IMO, users would prefer this over type-based equality, because it allows
float(1.0) == double(1.0); int(1) == unsignedInt(1); etc.

There is one point worth thinking about though: what's the value space
of
"anySimpleType"?

Places of the spec indicate that it's the union of the value spaces of
all
primitive types, but I always have difficulties accepting it. The reason
is
that anySimpleType doesn't have the ability to understand a lexical
representation, and convert it to an actual value. For example, if we
have
the lexical value "1.0", different primitive types know whether it's
valid,
and how to interpret it, but anySimpleType doesn't. So it's value space
should really be an empty set (or at most the value space of "string"
type,
but I don't like it). This seems to violate the "derivation constraints
value space" rule. But since we already made some exceptions for
primitive
types deriving from anySimpleType, it won't hurt to have one more.


BTW, it'd be appreciated if someone could answer my other questions:
1. what are the values of totalDigits/fractionDigits for decimal "0.00"?
2. Whether international decimal characters that are out of the range
#x30~#x39 (#x660, for example) are allowed in date time types?

Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com





                    "Ashok

                    Malhotra"            To:     Sandy
Gao/Toronto/IBM@IBMCA, <www-xml-schema-comments@w3.org>
                    <ashokma@micro       cc:

                    soft.com>            Subject:     RE: Questions
about "equal" fundamental facet


                    04/24/2002

                    04:59 PM

                    Please respond

                    to "Ashok

                    Malhotra"








Sandy, see comments inline.


All the best, Ashok


===========================================================


-----Original Message-----
From: sandygao@ca.ibm.com [mailto:sandygao@ca.ibm.com]
Sent: Wednesday, April 24, 2002 11:43 AM
To: www-xml-schema-comments@w3.org
Subject: Questions about "equal" fundamental facet


1. Is it defined on "value spaces", or "types"?


In 4.2.1 of the datatype spec: "Every *value space* supports the notion
of


equality, ...". So it seems that "equal" is defined on "value spaces".
Does


this imply that two (unconnected) types (with the same value space) can


have equal values? For example, hexBinary and base64Binary have the same


value space ("the set of finite-length sequences of binary octets").


hexBinary value "00" and base64Binary value "AA==" both represent one
byte


of value "0". Then are the two values equal? I would say they are equal,
if


"equal" is defined on value spaces.


But 3.11.1 of the structure spec says "Values of differing type can only
be


equal if one type is derived from the other, and the value is in the
value


space of both". Here it seems to indicate something different. Is this a


contradiction?


[AM] Equality is defined on values.  The values must be in the same
value
space. Since derivation by restriction merely narrows the value space a
value of a base type may equal a value of a derived (by restriction)
type.





2. Does the types have to be related by *restriction* or *union*?


If type A restricts "integer" by setting "minInclusive=0", and B
restricts


"integer" by setting "maxInclusive=10". Now A and B are not related by


restriction or union. But I still expect value "5" from both types
(values


spaces) to be equal.


(If they have to be related by *restriction* or *union*, doesn't 3.11.1
of


the structure spec need to be modified to be more strict, instead of
simply


saying "derived from"?)


[AM] By restriction.





My take on these 2 questions:


1. "equal" should be defined on value spaces, because equal values are


equal, no matter how they were lexically represented.


[AM] Correct!


2. Types used to generate equal (actual) values don't need to be
related.


As long as there exist a (primitive) value space to which both values


belong, and the two values are equal in that value space, then they are


equal. This means hexBinary and base64Binary can generate equal values,
so


can QName and NOTATION. Further on this, maybe the value space of
"float"


should (or already is) be a subset of that of "double", so that these
types


can generate equal values.


[AM] I don't know how to tell if two value spaces are subsets of some
primitive value space.  I only know such a relation exists for types
derived by restriction.


Thanks,


Sandy Gao


Software Developer, IBM Canada


(1-905) 413-3255


sandygao@ca.ibm.com

Received on Thursday, 25 April 2002 14:44:57 UTC