• From: Mukul Gandhi <gandhi.mukul@g...>
• To: "Costello, Roger L." <costello@m...>
• Date: Wed, 1 Feb 2012 21:24:16 +0530

Hi Roger,
   Nice examples.

Here are possibly two more approaches that may be possible for this
use case (these are XSD 1.1 specific). Both of these use the wild-card
element to specify variable nature of the content, and restricting the
content possibilities via assertion.

a)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

     <xs:element name="suitcase">
	    <xs:complexType>
		   <xs:sequence>
		         <xs:any minOccurs="3" maxOccurs="3"/>
		   </xs:sequence>
		   <xs:assert test="deep-equal(*/name(),
('shorts','Hawaiian-shirts','sunglasses'))
		                                or
					    deep-equal(*/name(), ('dress-shirt','tie','jacket'))"/>
		</xs:complexType>
	 </xs:element>
	
	 <xs:element name="shorts" type="xs:string" />

	 <xs:element name="Hawaiian-shirts" type="xs:string" />

	 <xs:element name="sunglasses" type="xs:string" />

	 <xs:element name="dress-shirt" type="xs:string" />

	 <xs:element name="tie" type="xs:string" />

	 <xs:element name="jacket" type="xs:string" />
			
</xs:schema>

pros about this approach: since the wild-card in this case has
specifier processContents="strict", therefore the XML instance
structure validated by the wild-card is strongly typed.

cons about this approach: to use the "strict" wild-card, the element
declarations that validate the XML instance elements that need to be
validated by the wild-card need to be global element declarations.
This has side effect of passing validation of the top-most XML
instance elements that are validated by these *wild-card provider*
element declarations.

b)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

     <xs:element name="suitcase">
	    <xs:complexType>
		 <xs:sequence>
		      <xs:any minOccurs="3" maxOccurs="3" processContents="skip"/>
		 </xs:sequence>
		 <xs:assert test="not(*/*)"/>
		 <xs:assert test="deep-equal(*/name(),('shorts','Hawaiian-shirts','sunglasses'))
		                              or
					  deep-equal(*/name(),('dress-shirt','tie','jacket'))"/>
	   </xs:complexType>
     </xs:element>
			
</xs:schema>

pros of this approach: this is a shorter schema than the first one
(possible due to the wild-card "skip" mode) and it doesn't suffer from
the cons of the first approach.

cons of this approach: the wild-card relies entirely on the assertions
to constraint (i.e to enforce some kind of typing) XML instance
structure that is validated by it. for this trivial case the <assert>
in this example does this correctly & completely (the first assert
enforces simple content for corresponding instance elements), but to
constrain deep XML fragments via <assert> may be hard (i.e simulating
a generic complexType).

Needless to mention: there may be various ways to solve a problem :)

On Tue, Jan 31, 2012 at 6:34 PM, Costello, Roger L. <costello@m...> wrote:
> Hi Folks,
>
>
>
> Consider the problem of designing an XML Schema for a suitcase that has
> different content depending on the travel purpose. For example, if going on
> a vacation then the content of suitcase is shorts, Hawaiian shirts, and
> sunglasses; if going on a business trip then the content of suitcase is
> dress-shirt, tie, and jacket.
>
> The suitcase has varying content. The suitcase is called a variable content
> container.
>
> The XML Schema Best Practice for variable content containers describes four
> methods for creating variable content containers:
>
> Use an abstract element and element substitution
> Use a <choice> element
> Use an abstract type and type substitution
> Use a dangling type
>
> http://www.xfront.com/VariableContentContainers.html
>
> This message describes a fifth method. It uses a schema’s context to provide
> content for its variable content container.
>
> Method 5: Implementing variable content containers using context schemas
>
> The following XML Schema document -- vacation.xsd --  includes suitcase.xsd:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            targetNamespace="http://www.trip.org/vacation"
>            elementFormDefault="qualified">
>
>     <xs:include schemaLocation="suitcase.xsd" />
>
>     <xs:complexType name="clothes">
>         <xs:sequence>
>             <xs:element name="shorts" type="xs:string" />
>             <xs:element name="Hawaiian-shirts" type="xs:string" />
>             <xs:element name="sunglasses" type="xs:string" />
>         </xs:sequence>
>     </xs:complexType>
>
> </xs:schema>
>
> Here is a second schema document -- business-trip.xsd -- that also includes
> suitcase.xsd:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            targetNamespace="http://www.trip.org/business-trip"
>            elementFormDefault="qualified">
>
>     <xs:include schemaLocation="suitcase.xsd" />
>
>     <xs:complexType name="clothes">
>         <xs:sequence>
>             <xs:element name="dress-shirt" type="xs:string" />
>             <xs:element name="tie" type="xs:string" />
>             <xs:element name="jacket" type="xs:string" />
>         </xs:sequence>
>     </xs:complexType>
>
> </xs:schema>
>
> Both vacation.xsd and business-trip.xsd are context for suitcase.xsd. Both
> have a different namespace. Both define a complexType, clothes.
>
> Now let’s examine suitcase.xsd. It is a no-namespace schema document. It
> declares a suitcase element and depends on context for filling in its
> content (for providing a definition of “clothes”):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
>     <xs:element name="suitcase" type="clothes" />
>
> </xs:schema>
>
> If the context schema document is vacation.xsd then the content of suitcase
> is shorts, Hawaiian shirts, and sunglasses. If the context schema document
> is business-trip.xsd then the content of suitcase is dress-shirt, tie, and
> jacket.
>
> Also notice that due to the Chameleon Effect the suitcase element is
> namespace-coerced to the namespaces http://www.trip.org/vacation and
> http://www.trip.org/business-trip, respectively.
>
> This example illustrates a context-dependent data model -- the suitcase
> element depends on its context (environment) schemas to complete its content
> model.
>
> Assessment
>
> Method 5 is similar to method 4 (dangling types) but with one important
> difference: with method 4 the schema used to specify the content of the
> variable content container is specified in the XML instance document whereas
> with method 5 the schema used to specify the content of the variable content
> container is specified in the content schema. Thus, method 4 is a run-time
> association whereas method 5 is a compile-time association. That may be an
> important difference for your situation.
>
> As with all engineering approaches, there are advantages and disadvantages.
> Let’s list them for method 5.
>
> Advantages
>
> -          Dynamic: A schema which depends on its context is dynamic. It
> does not statically hard-code the identity of a schema item to implement the
> content. Rather, it empowers schema developers that use a context schema to
> identify content.
>
> -          Applicable to any Schema Item: The context schema is not limited
> to only complexTypes. It can provide elements, attributes, simpleTypes,
> complexTypes, in fact, any schema item. Thus, this method is useful for more
> than just variable content containers.
>
> Disadvantages
>
> -          Context-Dependent Validation: A schema which depends on its
> context cannot be validated in isolation. It can only be validated in
> combination with its context schemas.
>
> FAQ
>
> Question: suitcase.xsd isn’t valid because type=”clothes” hasn’t been
> defined, right?
>
> You are correct. When taken independent of context suitcase.xsd is invalid.
> Suitcase.xsd depends on a context schema for validity. Thus, don’t validate
> suitcase.xsd. Instead, validate vacation.xsd or business-trip.xsd.
>
> This method turns things around 180 degrees from how one ordinarily thinks
> about XML Schema design. When designing schemas one doesn’t ordinarily
> think, “Oh, I’ll let the context (environment) schema documents provide the
> content here.”
>
> While it does require a mental shift, I think method 5 may be capable of
> modeling the real world in a better way. After all, in the real world
> context plays a key role in most everything. Method 5 simply reflects that.
>
>
>
> Questions for you:
>
>
>
> 1.       Have you used the Method 5 approach? Did it work out well?
>
> 2.       What other advantages and disadvantages do you see for Method 5?
>
>
>
> /Roger



-- 
Regards,
Mukul Gandhi