RE: Enumerated complex types

The WG is currently leaning against the idea of allowing assertions to
reference external documents. But the current Saxon-SA 9.0 implementation of
assertions allows it. This enables you to define a file error-codes.xml

<error-codes>
  <error>
    <code>0001<code>
    <status>fatal</status>
    <desc>Minor fire detected in hard disk drive</desc>
  </error>
  ...

and your schema can then say

<xs:complexType name="errorType">
  <xs:assert test="some $e in document('error-codes.xml')/*/error satisfies
deep-equal(., $e)"/>

Personally I think this is really useful and would like to see it allowed by
the specification.

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Guillaume Lebleu
> Sent: 20 December 2007 00:32
> To: xmlschema-dev@w3.org
> Subject: Enumerated complex types
> 
> 
> Hello,
> 
> I was wondering if the use case of enumerated complex types 
> had ever come up in this list. I did a quick search and 
> couldn't find anything.
> 
> Here is what I mean:
> 
> Let's say I want to define a list of error codes, each having 
> a possible value, an associated severity level and 
> description, which I have specified in the form of a table, 
> and I want to return in an XML message this information in 
> the form of a <Status> aggregate containing a <StatusCode> 
> element, <Severity> element and <Desc> element. This is a 
> realistic use case you can find in industry standards such as 
> IFX and ACORD.
> 
> One solution would be to use co-constraint rules: if 
> StatusCode is '100' 
> then Severity must be 'Error' and Desc must be 'General 
> Error', but that sounds quite complicated and it wouldn't 
> help the manual edition of a schema-compliant XML document.
> 
> The alternative solution I'm thinking about would be 
> something similar to the xs:restriction and xs:enumeration 
> used in simpleTypes, but with a value that would essentially 
> be an XML document fragment.
> 
> I see several advantages to this representation:
> 
>     * It could be leveraged to accelerate the manual edition of XML
>       instances of an XML Schema through code completion: I select one
>       of the enumerations in a drop-down list, just like today XML
>       editors allow me to select an enumerated value from a 
> drop-down list.
>     * It is easier than co-constraint representation for 
> business people
>       to understand and edit.
>     * It might be easier for type checkers to deal with (intuition).
> 
> Let me know what you think and sorry if this has already been 
> discussed.
> 
> Guillaume
>

Received on Thursday, 20 December 2007 00:47:40 UTC