Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: Peter@ursus.demon.co.uk
- Date: Fri, 11 Apr 1997 06:37:13 -0400
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
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)
> 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 ...>
html NAME #FIXED "p">
<!ELEMENT fraction ...>
math NAME #FIXED "frac">
<!ELEMENT sym ...>
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
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 email@example.com
Microstar Software Ltd. firstname.lastname@example.org
University of Ottawa email@example.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)