This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the XML Schema 1.1 specification at, http://www.w3.org/TR/xmlschema11-1/ an example for assertions feature is given as (in the section, 3.13.2): <xs:complexType name="intRange"> <xs:attribute name="min" type="xs:int"/> <xs:attribute name="max" type="xs:int"/> <xs:assert test="@min le @max"/> </xs:complexType> As per the XPath 2.0 specification (at, http://www.w3.org/TR/xpath20/), the operator "le" is defined for following operand types: numeric, numeric xs:string, xs:string xs:date, xs:date and many other types of operands. It seems to me, that above complex type definition assumes that the XML Schema 1.1 processor would perform the XPath 2.0 operation @min le @max by implicitly converting the values @min and @max to numeric, at runtime. Does the assertion processor has to infer the type of @min and @max from the types of attribute declarations (i.e., from the syntax xs:attribute)? I am thinking, that the above assertion component should have been written like, <xs:assert test="xs:int(@min) le xs:int(@max)"/> Could you please clarify this? Regards, Mukul
[Speaking only for myself, not on behalf of the WG] Thank you for your comment. Every reader of the draft spec is appreciated. Interesting that you should raise this issue. In designing the assertions construct, the WG spent a lot of energy debating whether it was desirable, highly desirable, essential, or desirable but not essential for the content and attributes of elements to be typed in the data model instance used to check assertions. Your comment provides empirical evidence that the proposition "all users will expect the attributes to have their typed values, not untyped values, and will not understand what is going on if they are untyped" is false; there is at least one exception. However, the WG concluded that it would be convenient if, for assertions checked on an element, the attributes and descendant elements were typed, and so we looked for, and found, a way to specify that behavior without logical contradiction. The rules for constructing the data model instance and evaluating the XPath expression, which are given in section 3.13.4, arrange things so that in the example you cite @min le @max the 'min' and 'max' attribute have already been validated as instances of xs:int and the data model instance contains their typed values. So the cast you propose xs:int(@min) le xs:int(@max) is unnecessary (although probably harmless). If you want chapter and verse, it is clauses 1.2 and 1.3 of Validation Rule: Assertion Satisfied which cause the attributes to be typed in the XDM instance. If it wasn't clear to you as a reader that the attributes in your example would be typed as int, then as editor I apologize: the text isn't doing its job perfectly if readers are surprised in this way. I would suggest adding some explicit statement on the topic to the description of assertions earlier in the section, except that I do not know how to say it more clearly than it is already said in the paragraph before last of section 3.13.1, which begins: To check an assertion, an instance of the XPath 2.0 data model ([XDM]) is constructed, in which the element information item being ·assessed· is the root element, and elements and attributes are assigned types and values according to XPath 2.0 data model construction rules, with some exceptions. Perhaps the prose following the example you refer to could be changed from The value of the min attribute must be less than or equal to that of the max attribute. to The value of the min attribute must be less than or equal to that of the max attribute. Note that the attributes are validated before the assertion on the parent element is checked, so the typed values of the attributes are available for comparison; it is not necessary to cast the values to int or some other numeric type before comparing them. Would that help?
It's a sensible question to ask. The example is correct, though one could argue that it would be more useful to the reader if there was a more detailed explanation given. Validation Rule: Assertion Satisfied, clause 1, explains how an XDM instance is constructed to act as the target for evaluating the XPath expression in an assertion. The note: "Note: It is a consequence of this rule that the [attributes] and [children] of E will be validated in the usual way." sums up what happens: the attributes and children of E (the element on whose type the assertion is defined) are validated before E is validated, and this validation results in them acquiring type annotations. So this assertion test="@min le @max" is comparing two attribute nodes with the type annotation xs:int. Explicit casting to xs:int is therefore not needed. Michael Kay (personal response)
Hello cmsmcq and Mike, Thanks for your comments and clarifications. Now I am clear about the concepts mentioned in this thread. You might close this bug report. Regards, Mukul
The XML Schema WG discussed this issue briefly at its call today. We instructed the editors to modify the commentary on the example in quesiton, as described in comment 1. Since the originator of the issue has suggested in comment 3 that he's satisfied even without that change, I'm marking this issue RESOLVED with disposition of FIXED. A copy of this comment should go by email to Mukul Gandhi, the originator of the issue; it is to him that the following remarks are addressed. Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next ten days or so, we will assume you agree with the WG decision.
Thanks for your consideration to discuss this issue. I am happy with the explanation in this thread, and the resolution of the issue. As suggested, I am marking this issue closed. Regards, Mukul