Namespaces, Architectural Forms, and Sub-Documents

[Paul Prescod]

Eve L. Maler wrote:
> 
> Table models, even if they're not CALS, are going to vary their content
> unpredictably, because cells typically need to contain markup *inside* them
> that is specific to the information domain *outside* the table structure;
> they're surrounded coming and going.  

There are many other situations where we have the same problem, but just
don't recognize it. Think about lists, bibliographies, cross references
and so forth. We shouldn't have to reinvent these for each DTD. There
are probably a short list of interesting parameterizations on them (for
most apps) and we should just include and use them (after specifying the
relevant parameterization options). Nobody has tried this (much) in the
past because module usage in SGML is just too painful. So only CALS
tables and a few other constructs are complex enough that the pain
involved in reinventing them outweighs the pain involved in using them
from a module. But if we massively reduce the pain in reusing element
declarations, we will probably see people reusing them a lot more.

That means that we need a convenient parameterization syntax and
namespace managment. Actual DTD fragment management would also be very
useful. Perhaps the Web can start to serve that role (for those that
can't afford full databases).

 Paul Prescod
--
http://itrc.uwaterloo.ca/~papresco


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