Re: [Bug 5906] Problem in definition of <restriction> in <complexType>::<simpleContent>

Thanks, Mike for a very helpful reply. Now I am more clear about this issue.

Sandy's response, mentioned
<quote>
adopted a proposal to address this issue by changing the facet element
name from "assert" to "assertion".
</quote>

So I think, the grammar fragment would become (for simpleContent/restriction):

Content: (annotation?, (simpleType?, (minExclusive | minInclusive |
maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale |
minScale | length | minLength | maxLength | enumeration | whiteSpace |
pattern | assertion | {any with namespace: ##other})*)?, ((attribute |
attributeGroup)*, anyAttribute?), assert*)

is this the only thing about this fix?

or are there any other details?

On Wed, Oct 15, 2008 at 7:51 PM, Michael Kay <mike@saxonica.com> wrote:
> The problem can be seen in the content model for simpleContent/restriction
> in 3.4.2.2, which reads
>
> Content: (annotation?, (simpleType?, (minExclusive | minInclusive |
> maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale |
> minScale | length | minLength | maxLength | enumeration | whiteSpace |
> pattern | assert | {any with namespace: ##other})*)?, ((attribute |
> attributeGroup)*, anyAttribute?), assert*)
>
> Note that "assert" appears twice. In the first case it appears in its role
> as a facet, to restrict the simple content type; this assertion works solely
> on the atomic value, for example you could restrict a number to be a
> multiple of 5 using <xs:assert test="$value mod 5 = 0"/>. In the second case
> it appears as an assertion on the element as a whole, including its
> attributes, for example you could assert that if @currency="JPY", then the
> value must be an integer: <xs:assert test="if (@currency='JPY') then $value
> mod 1 = 0"/>.
>
> But syntactically, there is no way of telling which assertion is which. So
> the simple solution (not a very elegant one, I have to say) is to rename one
> of them.
>
> I think this is actually a consequence of some poor syntax design in 1.0; I
> have always found the syntax of complex-types-with-simple-content very
> unnatural. But we have to live with it.
>
> Thanks for your interest in the development of the spec!
>
> Michael Kay
> http://www.saxonica.com/


-- 
Regards,
Mukul Gandhi

Received on Wednesday, 15 October 2008 14:58:46 UTC