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@s...>
To: "'Dieter Menne'" <dieter.menne@m...>; <xmlschema-dev@w...>
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@w...
>> [mailto:xmlschema-dev-request@w...] On Behalf Of Dieter Menne
>> Sent: 02 April 2009 19:06
>> To: xmlschema-dev@w...
>> 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.
>>
>>
>>
>
>
>



From lists@n... Mon Apr 06 14:41:17 2009
Received: from bart.w3.org ([128.30.52.63])
	by frink.w3.org with esmtp (Exim 4.63)
	(envelope-from <lists@n...>)
	id 1Lqq0j-0004oN-Pb
	for x