- From: Pete Cordell <petexmldev@codalogic.com>
- Date: Mon, 6 Apr 2009 11:31:10 +0100
- To: "Michael Kay" <mike@saxonica.com>, "'Dieter Menne'" <dieter.menne@menne-biomed.de>, <xmlschema-dev@w3.org>
I don't know whether this is possible, but could you define an attribute in another namespace, such that you do: <xs:element name="patients" minOccurs="0" maxOccurs="1" hrm:context-specific="true"/> and then have a style sheet that says if @hrm:context-specific is present, modify the minOccurs and maxOccurs attributes appropriately for the mode you want? One benefit is that the base schema is still a valid schema and hence might be easier to work with. It appears to self-document quite well also. HTH, Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ for more info ----- Original Message ----- From: "Michael Kay" <mike@saxonica.com> To: "'Dieter Menne'" <dieter.menne@menne-biomed.de>; <xmlschema-dev@w3.org> Sent: Monday, April 06, 2009 11:04 AM Subject: RE: Conditional Levels of a Schema > > > 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 > http://www.saxonica.com/ > >> -----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 > 4p22842334.html >> Sent from the w3.org - xmlschema-dev mailing list archive at >> Nabble.com. >> >> >> > > >
Received on Monday, 6 April 2009 10:32:01 UTC