[oXygen-user] Automatically generating XML schemas using XSLT

[Mark Baker]

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
> -----Original Message-----
> From: Olumide [mailto:videohead at mail.com]
> Sent: November 21, 2012 2:45 PM
> To: Mark Baker; oxygen-user at 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
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
>