[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|