- From: Curt Arnold <curta@hyprotech.com>
- Date: Sat, 16 Dec 2000 00:46:42 -0600
- To: <www-xml-schema-comments@w3.org>
The forms appear to have lose any sample markup when the summary page is
presented. I'll try to recreate my responses to a couple of questions that
had substantial markup embedded.
Order on timeDuration:
Both the draft and this form omit the a "D" in P1M10D < P50[D]
The evaluation described in the text seems extraordinary complicated (maybe
you should publish a reference implementation of the algorithm in Java).
I do believe that it does have to be ordered, however I would have any
comparison between non-zero precise (days, hours, minutes, seconds only) and
imprecise terms (containing months or years) or any comparison to a mixed
imprecise/precise duration to be false. So that if you added a
<xsd:minExclusive value="P1D"/> to a time duration, it would have the effect
of applying a pattern that would exclude the Y and M (except for the case of
P0M).
Likewise a imprecise constraint would have the effect of excluding days,
hours, etc from any acceptible value. That's got to be preferable to saying
you can't apply any min/max constraints on time duration.
I don't believe the value of fuzzy constraint evaluation is worth the
overhead. If you are really concerned about a constraint on a duration, them
limiting yourself to either exclusively imprecise (PnYnM) or precise
(PnDTnHnMdd.ddS) domains should be acceptible.
Also, there seems to be no discussion of a canonical form for time duration.
I would assume that it would be of the form P[nM]T[ddd.dddS] where the n =
12*Y + M in canonical integer form (term omitted if zero) and ddd.ddd =
D*86400+H*3600+M*60+S in canonical decimal format.
Order of content model and attributes:
Stylistically, I'd prefer attributes to be first.
I'd also would like a single element or any attribute to be acceptible in
the content model for complexType and complexContent, so you could do:
<xsd:complexType>
<xsd:any minOccurs="0" maxOccurs="unbounded"/>
</xsd:complexType>
instead of having to do:
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:complexType>
Other comments:
I had some examples in my reiteration the call for an <xsd:prohibit>
construct to prevent kludgey <xsd:unique>'s from
(http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JulSep/0010
.html)
However, I think the original message is sufficient to get the point across.
I did try to play today with the Oracle Schema Processor (the only
implementation of xsd:unique that I know of) to see if I could craft an
<xsd:unique> clause that effectively did an attribute cocurrence constraint,
but I kept getting null pointer exceptions.
Received on Saturday, 16 December 2000 01:46:09 UTC