I have the same kind of issue in the SPFE Open Toolkit. Schemas are highly modular, and sometimes the details you want in a particular low level schema depend on what you are trying to achieve in the higher level schema. To accomplish this without duplication, I use groups. Essentially, the trick is this: 1. Place reusable or variable elements in groups in the lower-level schemas. 2. In the high level schemas, define high-level groups containing whatever groups (defined in the low level schemas) that you want used throughout your resulting schema. 3. In the low level schemas, use the high-level groups to encapsulate variations that depend on which high level schema the low level schema is being included in. In other words, use groups in the high-level schemas to determine what features are turned on in the lower-level schemas. That explanation may be a bit hard to parse, but you can see an example of the technique at work in the SPFE Open Toolkit on GitHub: https://github.com/mbakeranalecta/spfe-open-toolkit/blob/master/spfe-docs/sc hemas/authoring/roots/element-descriptions.xsd Mark
-----Original Message----- From: oxygen-user-bounces@oxygenxml.com [mailto:oxygen-user- bounces@oxygenxml.com] On Behalf Of Olumide Sent: November 21, 2012 1:27 PM To: oxygen-user@oxygenxml.com Subject: [oXygen-user] Automatically generating XML schemas using XSLT
Hello,
Following this tutorial (http://www.liquid- technologies.com/Tutorials/XmlSchemas/XsdTutorial_04.aspx -- don't worry, I use Oxygen ;-) ) I've refactored my 733 line schema into 16 separate files or sub-schemas, each with its own namespace. Now the top level schema is just 77 lines. The plan is to use these sub-schema's to build other top-level schemas.
The problem is that most top level schema's are quite similar and only differ in a few low level details. For example while one top level schema supports all PaymentMethodType's (see tutorial) another top-level schema may support only VISA and MasterCard. Currently my method of creating top-level schemas involves considerable duplication. For example, my current method of creating a top-level schema in which only VISA and MasterCard are supported would involve duplicating Main.xsd and OrderType.xsd, but customizing CommonTypes.xsd and reuse CustomerTypes.xsd. (As my actual schema is a lot longer a lot more duplication is involved.)
I find this duplication unacceptable primarily because it introduces a maintenance challenge i.e. I would have to maintain any number of identical sub-schemas with different names.
What I would like to know is if there is a method of automatically generating a schema without via a config file of some sort (XSLT perhaps?), in order to avoid duplicating sub-schemas.
Also, is it good practice for all the sub-schemas to declare the same target namespace in this case (just like the xml schema namespace xs, but have custom sub-schemas declare a separate namespace?
- Olumide
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user