various issues

[David Megginson]

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

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
University of Ottawa            dmeggins at uottawa.ca
        http://www.uottawa.ca/~dmeggins

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