Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: Peter@ursus.demon.co.uk (Peter Murray-Rust)
- Date: Thu, 10 Apr 1997 06:41:48 -0400
Peter Murray-Rust writes:
> This sounds exactly what is needed but the bad news is that I
> know nothing about architectural forms. I suspect this is true for
> some other readers of this list as well. I would be grateful for
> any pointers (and brief explanations here if possible.) Here are
> some very naive questions...
For a quick introduction to Architectural Forms, see
For other information, see
> - are AFs part of HyTime or more generally part of SGML?
Architectural forms were originally specific to HyTime, but in the
forthcoming Annex 1 of the standard, they have been generalised --
HyTime is one base architecture, but DSSSL is another, as is the
Canadian GILS project.
> - does XML support AFs without further revisison?
> - if not, what has to be added? or is it possible to build this
> into tools without breaking the spec?
> - if tools have to be built, is the processing required at
> parser level?
There are different ways of dealing with AFs. James Clark's SP
library can do special, smart AF processing, where it actually parses
the document as if it were an instance of the base architecture rather
than of the derived architecture, but that is not always necessary (or
desirable). XML-based tools can simply look for the <?ArcBase ...?>
processing instruction and the associated notation declaration, and
then use the attribute values for processing.
NXP-based apps, for example, should be able to handle this, but
DTD-less parsing will not be possible unless the attribute values are
included in the document instance itself (I consider this a feature
rather than a bug).
The one short-coming is that XML does not support data-attributes, so
it will not be possible to customise the AF support -- you'll have to
stick with the defaults.
> - do the components belonging to different DTDs have to live in
> separate files or can they be separated within a single
> file (e.g. by NOTATIONs)?
They should be stored in separate files (etc.), just like public
> - if someone decides they need AFs are they easy to implement?
> (for my requirements it looks like an aliasing mechanism
> would suffice.
This _is_ an aliasing mechanism, of sorts.
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)