W3C home > Mailing lists > Public > xmlschema-dev@w3.org > June 2012

Re: Supporting incremental-definition of a type?

From: Mukul Gandhi <gandhi.mukul@gmail.com>
Date: Tue, 19 Jun 2012 06:43:56 +0100
Message-ID: <CABuuzNPaj0g6opnnnpuJh6v8vz4cRfRMzACtJbamVxSzLEaGxw@mail.gmail.com>
To: xmlschema-dev@w3.org
Cc: Michael Kay <mike@saxonica.com>
On Mon, Jun 18, 2012 at 10:47 PM, Michael Kay <mike@saxonica.com> wrote:
> So if I have a type A and I want to define a type B that restricts A with an assertion, the simplest way is
> to define B as a "vacuous extension" of A. Non-obvious, but very useful.

Here's a simple schema example I came up with,

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="X">
          <xs:complexType>
	       <xs:complexContent>
		      <xs:extension base="T1">
			   <xs:sequence>
			        <xs:element name="y" type="xs:integer"/>
			   </xs:sequence>
			   <xs:assert test="x gt y"/>
		     </xs:extension>
		</xs:complexContent>
	  </xs:complexType>
   </xs:element>

   <xs:complexType name="T1">
         <xs:sequence>
	      <xs:element name="x" type="xs:integer"/>
	 </xs:sequence>
   </xs:complexType>

</xs:schema>

An assertion being a co-occurrence constraint, in this case for
example enforces a relational constraint between two sibling elements
(and to me, this doesn't produce a restriction effect between complex
types, but rather is an orthogonal constraint on top of extension).

Assertions (for example, during XSD type extensions) must be used
carefully though. If the intention is to only produce an XSD particle
extension affect (like what XSD 1.0 did), then using assertion
improperly in such cases may inject a restriction behavior.



-- 
Regards,
Mukul Gandhi
Received on Tuesday, 19 June 2012 05:44:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:16:01 UTC