various issues

David Megginson dmeggins at
Fri Apr 11 12:39:46 BST 1997

Peter Murray-Rust writes:

 > Thanks for the discussion - I am certainly finding it very
 > interesting.  My impression is that implementing AFs at this stage
 > is a lot of work and also that there is a considerable amount of
 > simple tutorial material required (e.g. the SP material assumes you
 > are familiar with the HyTime standard.)

That wasn't my impression -- James certainly makes passing reference
to HyTime, but he does not seem to assume prior knowledge of the
standard (I first learned about AFs from James's doc, without [at that
time] any but a passing knowledge of HyTime).  That said, his doc is
not meant (I think) as a beginners' tutorial, though it is the closest
thing we have right now.

 > I'm not clear what the meta-DTD looks like, so here is a possible
 > problem:

It usually looks exactly like a regular DTD, unless you use a couple
of minor syntax extensions allowed (but not required) by the annex.
You could use DocBook, HTML 32, or TEI-Lite (to give three examples)
as meta-DTDs.

 > My DTD (CML) includes (say) HTML 3.2 which contains a SUB element.
 > Now suppose I want to incorporate another DTD which does maths -
 > let's call it MATH.dtd, and find that it has a namespace collision
 > with SUB.  Do I create a meta-DTD which describes two separate AFs?
 > If so, what does it look like (in very simple terms).

You do not include either DTD -- instead, you map some elements to
elements in the HTML DTD, some elements to elements in the math DTD,
some to neither, and some to both.  For example,

  <?ArcBase html?> <?ArcBase math?>

  [notations and entities omitted]

  <!ELEMENT para ...> 
  <!ATTLIST para
    html      NAME    #FIXED "p">

  <!ELEMENT fraction ...> 
  <!ATTLIST fraction
    math      NAME    #FIXED "frac">

  <!ELEMENT sym ...> 
  <!ATTLIST symbol
    html      NAME    #FIXED "sym" 
    math      NAME    #FIXED "symbol">

You still have to declare every element in your own DTD, whether or
not it is mapped to something in a meta-DTD.

 > > It would not be hard to implement data-attribute support in XML,
 > > but the committee might not be thrilled with the idea -- it will
 > > probably seem too much like creeping featurism.  I imagine that
 > > they will probably end up using processing instructions instead
 > > of data attributes.  I agree with Peter in preferring data
 > > attributes.
 >  Presumably one attraction of PIs is that the current parsers (and
 > XML-LANG spec) won't have to be changed?

The disadvantage is that, since data attributes are naturally
associated with a single notation, and notations are naturally
associated with a single base architecture, it is easy to keep track
of what goes with what.  Perhaps additional arguments to the <?ArcBase
...?> PI would be the best alternative.

 > I assume that it's easiest to build these systems if the two DTDs
 > don't interact at all (i.e. represent completely separate pieces of
 > information.)

Not necessarily: you will run into problems only if the overlapping
structures are different; the names are not an issue.

 > [I liked the article by Steve Newcomb - although again it assumed
 > some familiarity with HyTime in places.  It is clearly a vision
 > that I would wish to evolve towards though again the mian problem
 > is education.]

There is __no__ need to learn HyTime to understand Architectural
Forms.  HyTime is simply one of many possible base architectures.

All the best,


David Megginson                 ak117 at
Microstar Software Ltd.         dmeggins at
University of Ottawa            dmeggins at

xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list