This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The WG has issued a priority feedback request on the question of whether assertions should be allowed on simple types. For the record, I think they should. Here are some use cases: (a) consider an attribute (perhaps called xsi:schemaLocation) whose value consists of a list of URIs, such that the cardinality of the list must be an even number. There is currently no way to express this constraint. (b) consider an attribute whose value must be an integer that is a multiple of 10. This can be expressed clumsily using a pattern. But what about an integer that is a multiple of 20? or 7? (c) consider a date that must be in the past, or in the future. (d) consider a date that must not be a Saturday or Sunday Without assertions on simple types, there is a danger that users will attempt to define such assertions on some containing complex type, which is not where they correctly belong; misplacing the constraint in this way will inevitably lead to maintenance difficulties. I would propose that for assertions on simple types, the context item should be the string value of the element or attribute being validated, and the XPath expression will therefore not have access to any nodes. The examples above could be achieved with: (a) test="count(tokenize(., '\s+') mod 2 = 0" (b) test="number(.) mod 10 = 0" (c) test="xs:date(.) lt current-date()" (d) (xs:date(.) - xs:date('1901-01-06')) div xs:dayTimeDuration('PT1D') mod 7) gt 2
Phase I agreement: 1 yes, assertions on simple types 2 do not change the existing built-ins-only rule (n.b. this also prevents circularity) 3 appears as new property of simple types (not as new facet) 4 context item is string value of the item, as xs:untypedAtomic (alternatives: string value as xs:string, or string value as the appropriate primitive (anySimpleType for lists or unions), or string value as anySimpleType) 5 Assertions legal on restriction and on list and on union (i.e. any simple type constructor). (Alternative: on restriction only.) The WG discussed that another alternative for point 4 would be to use the base type, both for atomics and for lists, i.e. if I'm asserting something of a list of my:specialDate, take it into XPath as a list of xs:date. MKay said IIRC the context item cannot be a list. Ref: M. Kay's note http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Jan/0013.html
A wording proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5030.html http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b5030.html (member-only links)
The proposal mentioned in comment #2 was adopted by the WG at today's call. Michael, if you would please do the honors? If we don't hear from you in the next two weeks, we will be forced to assume that you approve of the adoption of your proposal.