Good tools and protocols should make it possible to create, transmit,
and process compound documents as if they were single files. This
will be necessary anyway for supporting multimedia.
Here are some general guidelines:
* Architectural forms are most suitable for applications where
multiple inheritance is required, or where elements belonging to a
different document type are scattered throughout a document.
* Sub-documents are most suitable for applications where all of the
element belonging to a different document type are rooted in a
single subtree.
"namespace:gi" element type names are unsuitable for several reasons:
1) The complexity of namespaces is exposed to the author rather than
hidden in the DTD (as it is, optionally, with architectural forms).
2) Multiple inheritance is not possible (X can be a kind of Y or a
kind of Z, but not both).
3) Standard DTD-based validation is not possible, and it is more
difficult to create DTD-driven authoring tools.
4) Both architectural forms and sub-documents can be fully supported
under the existing spec by _both_ validating and non-validating XML
parsers: no changes necessary. Furthermore, they will also remain
compatible with SGML tools.
Why are people worried about writing specs to solve a problem that
already has good, working, available solutions?
All the best,
David
--
David Megginson ak117@freenet.carleton.ca
Microstar Software Ltd. dmeggins@microstar.com
http://home.sprynet.com/sprynet/dmeggins/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)