Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
