Comments on 12/17 Schema Datatypes

1) In section 3.2.3.1, you say "If the "E" and the the following exponent are omitted, an exponent value of 1 is assumed."  The assumed exponent should be 0, not 1.  That is 1.2 is equivalent to
1.2E0, not 1.2E1.
2) I would try to discourage the use of float unless the reduced range and precision is a desired decision by the schema author.  To that end, I would have double as a primitive type and float as a
generated type derived from double.
3) It would be useful to have a facet for timeInstant, date and time that indicated whether a timeZoneOffset was required, allowed, prohibited or defaulted.*
4) In section, 3.2.7.1:
"P0Y1347M0D is not allowed" seems to add unnecessary complexity since you now have to do zero checking on all but the most significant part
"For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: 1Y2M3DT10H30M."  Actually you would write: P1Y2M3DT10H30M.
"Time periods, i.e. specific durations of time, can be represented by supplying two items of information: a start instant and a duration or a start instant and an end instant or an end instant and a
duration. "  Maybe this could be part of a non-normative appendix that suggests methods of representing some of the ISO 8601 constructs using the time related types in XML Schema.
"The number of seconds can include decimal digits to arbitrary precision", I think it would be simpler to say that the seconds term can adhere to the lexical production for double.  This allows both
extremely short and long time durations.
5) Section 3.2.7.2.
It would be useful to have a facet that constrain timeDurations to exact durations (that is, suppresses years and months that cannot be unambiguously converted to a duration in seconds).*
6) Section 3.2.8
I still don't like recurringInstant.  I still adds a lot of unnecessary complexity and goes against the XML design principle of favoring simplicity over terseness.  I think that date and time should
be primitive types of their own and the avoid the mental gymnastics to find a common ancestor type.  Patterns for truncated forms of ISO 8601 might be handled in a non-normative appendix.*
7) Use of case in type names
The cases used for some names are awkward.  I can see (but don't prefer) using all caps for types that are equivalent to XML 1.0 DTD "types", however the Name, QName and NCName don't feel right.  I'd
prefer names to be almost exclusively lower case (with exceptions like timeDuration).
8) Section 3.3.7 (and following)
Deriving ID from NCName adds a constraint to the value space (no colons) that wasn't in the XML 1.0 Spec.  An XML 1.0 document could have legal ID's like (I:didntAnticipateNamespaces) that would not
be valid by this definition.  However, since the use of colon was discouraged, the number of incidences should be small.  It is at least worth a comment, but I think that ID should be derived from
name not ncname.
9) Section 3.3.13
There is a little conceptual inconsistency between this section and the changes that have occurred in the real number domain.  In the previous versions, there was an abstract real datatype and an
abstract integer datatype.  These types were not constrained by any specific implementation, for example, 1E5673 would have been a legal real and integer would have supported unlimited length
integers.  In this draft, the abstract real has been replaced with two concrete implementations (double and float), but integer still remains abstract.
In a perfect world, I'd still have the abstract "real" datatype, double would be a derived type from "real" and float a derived type from "double".  In the integer side, the abstract "integer" would
derive from decimal and maybe "long" (32-bit), "short" (16-bit) and "byte" (0-255) would derive from integer.  Unsigned might be a facet for integers.  This should be distinct from a minInclusive,
since I may want to say that a value has a minimum of zero but used a signed type to avoid unintended rollover problems.
I'd drop the positive-integer stuff as long as I could easily specify a minInclusive or an unsigned facet.
10) section 3.3.18
I think the truncated forms add a huge amount of complexity and should be suppressed.  If they are supported, there needs to be a facet to suppress there use in a specific attribute.  For instance, if
I am definiting a date of birth attribute, I don't want to allow ---30-12.*

*A repetion of a point in previously (and more fully stated) in http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0037.html







.

Received on Monday, 3 January 2000 16:56:03 UTC