Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Enumerated complex types

From: "Michael Kay" <mike@--------.--->
To: "'Guillaume Lebleu'" <gl@---------.--->, <xmlschema-dev@--.--->
Date: 12/20/2007 12:47:00 AM

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@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Guillaume Lebleu
> Sent: 20 December 2007 00:32
> To: xmlschema-dev@w...
> 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
> 


From gl@b... Thu Dec 20 02:02:22 2007
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (E


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent