Re: Supporting incremental-definition of a type?

On 18/06/2012 21:22, Mukul Gandhi wrote:
> On Mon, Jun 18, 2012 at 4:21 PM, Michael Kay<mike@saxonica.com>  wrote:
>> Yes, this is a serious problem with the xs:restriction mechanism for defining subtypes, that you have to declare all the
>> parts of the content model that you want to leave unchanged, rather than the parts you are restricting away.
> XSD has it's own unique notion of how complexType restrictions work,
> and I would say you may find it quite strange if you're expecting it
> to work like an OO class inheritance for example.

I'm working at the moment on the schema for XSLT. I'm trying to add 
assertions so that the schema catches more static errors than it does at 
present, for example the rule that an xsl:param child of xsl:function 
must have no select attribute. This turns out to be surprisingly 
troublesome. It isn't possible to simply add the assertion to the type, 
because the type (like most types in this schema) is derived by 
extension from a type with empty content having a number of attributes. 
So we need to change this:

<xs:element name="function">
<xs:complexType>
<xs:extension base="X">
<xs:sequence>
<xs:element name="param"/>
<xs:group ref="sequence-constructor"/>
</
</
</
</

to this:

<xs:element name="function">
<xs:complexType>
<xs:restriction base="function-base-type">
<xs:group ref="function-model"/>
<xs:assert xpath="empty(xsl:param/@select)"/>
</
</
</

<xs:complexType name="function-base-type">
<xs:extension base="X">
<xs:group ref="function-model"/>
</xs:extension>
</xs:complexType>

<xs:group name="function-model">
<xs:sequence>
<xs:element name="param"/>
<xs:group ref="sequence-constructor"/>
</
</xs:group>

which is pretty disruptive just to add an assertion. It would be even 
more disruptive if the content model of the type had been built up by 
several extension steps, because the need to restate the content model 
as part of the restriction step would essentially destroy all the 
benefits of building it up incrementally.

Of course there would be other ways of doing it, like having local 
element declarations for xsl:param so the type depends on its parentage. 
But that's not really the point.

It's actually quite tempting to put all the assertions at the level of 
the xsl:stylesheet element, but I'm resisting that because it's likely 
to be expensive and give poor diagnostics.

I think it would have been much better if we had allowed assertions to 
be defined within an <xs:extension> - the semantics being to define an 
anonymous type by extension and then restrict this by assertion.

Michael Kay
Saxonica

Received on Monday, 18 June 2012 20:54:37 UTC