Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: various issues
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@f...
Microstar Software Ltd. dmeggins@m...
University of Ottawa dmeggins@u...
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@i... the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
