-----Original Message----- From: Olumide [mailto:videohead@mail.com] Sent: November 21, 2012 2:45 PM To: Mark Baker; oxygen-user@oxygenxml.com Subject: Re: [oXygen-user] Automatically generating XML schemas using XSLT
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
Olumide, Briefly (I can supply more detail later if you want). The schemas are split into sub-schemas. The example I pointed to is just one of the sub-schemas. The way I have it organized is this: * the top level schema is a wrapper that consists only of include statements. Since I am using a chameleon schema approach, this top level schema also establishes the namespace for the whole schema, but this would not apply to you if you are using separate namespaces for each component. The top level schema in this case has the same name but is one level up: https://github.com/mbakeranalecta/spfe-open-toolkit/blob/master/spfe-docs/sc hemas/authoring/element-descriptions.xsd . * I have a set of schema modules in a modules directory (or, in this case, more than one module directory). The wrapper schema includes whichever modules are required for the schema being defined. * I have a set of root schemas in a roots directory. The example I pointed to is one of these. The roots schemas define the root element and unique structures of a particular schema type, and include the definitions of the top-level groups. Those top level groups are defined by including groups defined in the modular schemas. For example, line 91 defines the p-content group: <xs:group name="p-content"> <xs:choice> <xs:group ref="text-decoration"/> <xs:group ref="mentions-general"/> <xs:group ref="mentions-xml"/> <xs:group ref="mentions-spfe-build"/> <xs:group ref="resources"/> <xs:group ref="substitutions"/> </xs:choice> </xs:group> The p-content group defines the elements that are permitted in a p element for this schema. Each one of the referenced groups defines elements that can occur inside a paragraph. Each of these groups is defined in one of the module schemas. Any time any of the module schemas declares a paragraph, their declare its content to be the p-content group. That way, the elements that are allowed in a paragraph are not defined in the module schema, but in the root schema. For example, the paragraphs schema module defines the paragraph-type like this: <xs:complexType name="paragraph-type" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:group ref="p-content"/> </xs:choice> <xs:attributeGroup ref="conditions"/> </xs:complexType> The mentions-xml group is defined in https://github.com/mbakeranalecta/spfe-open-toolkit/blob/master/spfe-ot/plug ins/eppo-simple/schemas/authoring/modules/mentions/mentions-xml.xsd as: <xs:group name="mentions-xml"> <xs:choice> <xs:element name="xml-element-name"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="xpath" use="optional"/> <xs:attribute name="namespace-uri" type="xs:anyURI" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="xml-attribute-name"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="xpath" use="optional"/> <xs:attribute name="namespace-uri" type="xs:anyURI" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="xml-namespace-uri"/> <xs:element name="xpath"/> </xs:choice> </xs:group> This means that in any paragraph for the particular schema I am defining, no matter which module it was defined in, the tags <xml-element-name>, <xml-attribute-name>, and <xml-namespace-uri> are allowed to appear. If the same module that defined the paragraph were included in another schema that did not include the mentions-xml in its definition of the p-content group, then those elements would not be allowed inside that paragraph. Essentially, then, I am using groups as a transclusion mechanism to pull definitions from one schema file to another, which eliminates the need to repeat common structured from one schema module to another. Hope this helps, Mark 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