W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2009

RE: Conditional Levels of a Schema

From: Michael Kay <mike@saxonica.com>
Date: Mon, 6 Apr 2009 11:04:56 +0100
To: "'Dieter Menne'" <dieter.menne@menne-biomed.de>, <xmlschema-dev@w3.org>
Message-ID: <65D406322FA54398815714FA96F6D2DC@Sealion>

This is a common requirement, and there's no simple answer to it.

One approach is to define restricted types: in your more general schema, the
item is defined as optional, and then you have types derived by restriction
than make it mandatory or prohibited. The instance document then has to
indicate which version of the type it wants to use by use of xsi:type; or
alternatively, if you schema validator allows it, you can indicate which
top-level type you want to validate the message against through your
validator's API.

There are a number of difficulties with this approach; one is that you not
only have to define restricted types for the element whose content model is
directly affected, but for its ancestor elements all the way up to the
top-level message structure. Because restrictions are defined by repeating
the content model rather than simply stating the differences, this can be a
maintenance nightmare.

One approach I have used in the past is to generate the schema documents
defining these restricted types automatically (using XSLT). This reduces the
maintenance burden - but in-house tools like this have their own problems in
terms of maintenance and documentation.

Probably a simpler approach, and one that is closer to your description of
the problem, is to implement the conditional logic not by generating
subtypes but simply by modifying the main type definition. Again you can do
this using XSLT: just define a stylesheet where the schema document is the
body of the <xsl:template match="/"> template rule, and it can then contain
things like <xs:element name="patients" minOccurs="{$param}"/> where $param
is a stylesheet parameter. One disadvantage of this approach is that
different variants of the schema cannot coexist in the same application -
typically your schema cache will only allow one version of a type with a
given name.

XSD 1.1 allows you to supplement the grammar constraints with assertions, so
for example the message in which the <patients> element is probited could be
defined using <xs:assert test="empty(//patients)"/>. You could also use
conditional type assignment at the message level to select the type for
validation based on a user-defined attribute such as @message-type. These
facilities are implemented in Saxon-SA 9.1 which you could use to explore
the concept.

Michael Kay

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Dieter Menne
> Sent: 02 April 2009 19:06
> To: xmlschema-dev@w3.org
> Subject: Conditional Levels of a Schema
> Hi,
> we are currently defining a format for medical data storage 
> (hrmconsensus.org). The full version is available 
> http://hrmconsensus.org/media/hrm/xhrm/xhrm02/xhrm0_2.xsd here .
> In the simplified example below, we have the always mandatory 
> deviceTyp. For patientsType, we would like to have a global 
> conditional switch so that three flavors are possible
> -- minOccurs = "0" for internal clinical use
> -- minOccurs = "1" for archiving, must contain patient info
> -- minOccurs = "never" anonymized, must not contain patient info
> I know that the latter is not possible, that conditionals are 
> not supported in XSL, and that Schematron would be an 
> alternative.  Note that the conditionals occur in several 
> nesting levels, so that we cannot easily combine versions of 
> a master element with details, but they are always of the 
> type "may", "must", "must not".
> We would like to avoid having several xsd files and prefer a 
> common file with branching. Any ideas or references to ideas 
> are appreciated.
> Dieter Menne
> on behalf of the hrmconsensus group.
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" version="0.2">
> 	<xs:element name="xhrm">
> 		<xs:complexType>
> 			<xs:sequence>
> 				<xs:element name="device" 
> type="deviceType"/>
> 				<xs:element name="patients" 
> type="patientsType" minOccurs="0"/>
> 			</xs:sequence>
> 		</xs:complexType>
> 		</xs:element>
> </xs:schema>
> -- 
> View this message in context: 
> http://www.nabble.com/Conditional-Levels-of-a-Schema-tp2284233
> Sent from the w3.org - xmlschema-dev mailing list archive at 
> Nabble.com.
Received on Monday, 6 April 2009 10:05:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:51 UTC