Entities (was Re: XSchema Spec, Sections 2.0 and 2.1 (Draft 1))

[David Rosenborg]

John Cowan wrote:

> That doesn't mean that I wouldn't be interested in defining an
> XML-level mechanism for XSchema piece reuse using element/attribute
> machinery.  The main question there is just what should be reusable.
> To my mind, the obvious choices are content models or parts thereof,
> and attributes or groups thereof.  Do you see anything else that
> could usefully be reused?

Hi!

I've been working on an XSchema-like (by concept) solution for
a couple of weeks. My first intent was to do "literate programming"
for our DTDs i.e integrate documentation into the DTDs.
I ended up with something that looks very similar to your
XSchema proposal with additional markup for documentation
(which has also been discussed on this list).

Having the power of managing my own framework for specification
structures (which is a weakness too, naturally) I thought that
I just as well could remove or rather replace the parameter entity
machinery (which I dislike). My short analysis gave the following
desired characteristics that I used parameter entities for earlier:

* Modularity
* Parameterisation
* Reuse

I implemented those with with the follwing constructs

* Inheritance of type, an "IsA" relation
* Inheritance of structure
* Use of structure by reference

Apart from the constructs you mention I also find
it usful to parameterise enumeration values in attribute
declarations.

IMO parameter entities (or general entities in XSchema instances)
are not good candidates for this. They work on a syntactic
level rather than on a structural level and more important,
they are imperative or explicit in contrast to declarative.
This makes them hard to use and maintain (e.g you must know
what will get expanded when and by whom). Instead I think
it is of greatest importance that native constructs for
basic inheritance and parameterisation are included XSchema.

Since simplicity is a motto I think parameter entities (and alike)
must go away. They might be somewhat simpler to implement and
understand (as a concept) since they are more primitive, but in
practice, the resulting schemas will be far more complex and hairy
compared to a declarative solution.

To be more concrete, the example below outlines my current
implementation. I expect to make the results of this public as
a case study on our website when it is complete.
Currently I use DSSSL in Jade to convert the schemas into
DTDs (and the code is fairly simple).

Cheers,

</David>

-----------------------------------------------------------------------
David.Rosenborg at xsse.se                        Stockholm Stock Exchange


Example:

My schema have a section <fragments> which can hold definitions
of parts of content models and attribute lists. The interesting
parts are the "implements" attribute and the base/extends construct.

First some common elements and constructs

<document-type name="common">
 <title>Common Elements</title>
 ...
 <fragments>
  <abstract-type name="chapter-content"/>
  <abstract-type name="emphasis"/>

  <mixed id="text">
    <element name="emphasis"/>
  </mixed>

 </fragments>

 <element-declaration>
  <name>chapter</name>
  <content-model>
    <sequence>
      <element name="title"/>
      <element name="chapter-content" occurence="zero-or-more"/>
      <element name="chapter" occurence="zero-or-more"/>
    </sequence>
  </content-model>
 </element-declaration>

 <element-declaration implements="chapter-content">
  <name>p</name>
  <content-model>
    <cm-ref linkend="text"/>
  </content-model>
 </element-declaration>

 ... 

</document-type>


The following is a simple document schema.


<document-type name="vanilla">
  <title>Simple Document</title>

  <!-- Inherits the common element set -->

  <base>
   <extends name="common"/>
  </base>

  <element-declaration>
    <name>vanilla-document</name>
    <content-model>
      <sequence>
        <element name="title"/>
        <element name="chapter" occurence="one-or-more"/>
      </sequence>
    </content-model>
  </element-declaration>

  <element-declaration implements="chapter-content">
    <name>note</name>
    <content-model>

      <!-- Extends a mixed contend model -->

      <mixed>
        <base>
          <extends name="text"/>
        </base>
        <element name="some-extra-element"/>
      </mixed>

    </content-model>
  </element-declaration>

  <element-declaration implements="emphasis">
    <name>strong</name>
    <content-model>
      <pcdata/>
    </content-model>
  </element-declaration>

  ...

</document-type>

The DTD generated for vanilla-doc:

<!ELEMENT vanilla-doc (title, chapter+)>
<!ELEMENT chapter     (title, (p | note)*, chapter*)>
<!ELEMENT p           (#PCDATA | strong)*>
<!ELEMENT note        (#PCDATA | strong | some-extra-element)*>
<!ELEMENT strong      (#PCDATA)>

...

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)