Lists Home |
Date Index |
- From: David Rosenborg <David.Rosenborg@xsse.se>
- To: XML Dev <email@example.com>
- Date: Tue, 9 Jun 1998 14:11:05 +0100
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?
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:
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
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).
David.Rosenborg@xsse.se Stockholm Stock Exchange
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
<element name="chapter-content" occurence="zero-or-more"/>
<element name="chapter" occurence="zero-or-more"/>
The following is a simple document schema.
<!-- Inherits the common element set -->
<element name="chapter" occurence="one-or-more"/>
<!-- Extends a mixed contend model -->
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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)