XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Creating Context-Dependent Data Models

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@mitre.org> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS