On 21/11/2012 19:12, Mark Baker wrote:
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.
It ... sort ... of makes sense. I'm going to have to set aside the book on XSLT and take a really close look. Or could you kindly highlight where in the schema you perform each one of these steps? BTW, you don't seem to have split your schema into sub-schemas. Inspired by your approach, it would be nice to have the varying elements share a common name but live in unique namespaces. For example the general version of the element Foo in the common namespace com and thus referenced as com:Foo, while the customized version of Foo be declared another namespace cus, and thus referenced as cus:Foo. The goal of course would be to find a way of identifying the appropriate Foo namespace in the top-level schema. Note that Foo may not appear in the top level schema, and is often deeply nested in other elements contained in the top level level schema. - Olumide