- 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