I'm tired of RE, so I'm going to address something more interesting
(though probably less important in terms of ultimate acceptance).
I agree with the general move to DTD-less processing, but I think that we
should make a requirement on all XML parsers: that they be _capable_ of
creating an XML DTD given a DTD-less instance. I thought at one time that
creating the DTD should be a requirement, but that's obviously retarded for
search and browsing applications.
I can see a few scenarios for why this is a good idea:
1. If I'm browsing and I find document that I want to use as a template for
a project of my own, getting a DTD for that document might be a good first
step for my authoring process. Since we can't guarantee that the DTD
exists, we should be able to make on on demand if it doesn't or we can't
2. If I'm authoring a light-weight document (like a letter), I frequently
want to use generic markup, but there is not a suitable DTD handy, nor the
time to try to create one from scratch. I'd like XML to give me at least
the flexibility that Word styles gave me for evolving a document type, when
I still used it as a writing tool. (Now I just use HTML for my own writing
unless it's a heavy duty project -- this is not exactly a step forwards).
3. It's an interesting and potentially productive way to get imput to DTD
definition projects: explain tag syntax and encourage people to "work up
some exaple documents." The resulting DTDs can help to find potential
problems, and also help to train the users in how to help develop DTDs.
Keith Schafer of OCLC described this apporoach at an SGML conference
session on FRED.
We should let tools compete on how they create this DTD (ANY, ANY, ANY is
the degenerate case), as there is no _right_ answer. Even a degenerate set
of ANY, ANY, ANY models gives me an element list as a starting point.
I think this also addresses the authoring question in the best way
possible. At any point, an user can ask to have a DTD made if they don't
have one (and maybe if they way to update the one they have to allow
something they've just decided to so). That DTD can me used for further
editing, changed, inspected in hopes of some kind of enlightenment, or
saved in a library for future use.
Here we don't force users to do what is good for them, but make it easy
for them to do it, once they realize what's up.
David Durand email@example.com | david@dynamicDiagrams.com
Boston University Computer Science | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/