Lists Home |
Date Index |
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
> At 2002-06-12 16:23 +1000, Marcus Carr wrote:
> >Could someone spell out the role that they see extended DTDs playing?
> >(Ken?) I'm not saying that there isn't one, just that it doesn't jump up and bite me.
> I'm hoping that will come out in the requirements and use-cases.
Here are some potential use-cases for you, Ken:
1) I have a growing set of documents, and I want to start adding documents
which have no DOCTYPE declaration. But I am happy with DTDs
so far, and want to put off deciding about RELAX or XML Schemas etc
for a year or so. So I just want to validate with my current DTD without
needing a DOCTYPE declaration.
2) I am moving my documents to XML namespaces. I want to treat
my current element sets as if they belong to a single namespace, but not
have to rewrite then to add xmlns attributes or prefixes. So I just
want them to be minimally namespace aware. For example, the
CALS table element set could be in one namespace, and DOCBOOK
3) I want the DTD content models to be open to elements of other
content models by default. Just like in XML Schemas, an element
in another namespace can be validated by looking up the appropriate
schema for that namespace.
But in general, I really don't think we need to spend much effort on
DTDs, just the minimal required to make them work with DSDL
> That's an important reason to have use-cases ... if the act of thinking out
> what it will do before how it does what it does reveals that it needn't do
> anything, that is an important result and it saves on a lot of work.
Yes. I hope XML-DEVers will feel free to send (to Ken, Eric or the other
editors, and/or to XML-DEV) any use-cases they have (in the broad publishing
and WWW areas), especially requirements that they may feel are important but
which don't really fit into schema languages for serializing and transfering DBMS
I think we are particularly interested in ideas that have been prototyped and
deployed for real publishing tasks.