Proposal for src files

[W. Eliot Kimber]

At 09:22 AM 4/1/98, Peter Murray-Rust wrote:
><PROPOSAL>
>Is it possible to combine these two so that we express a DTD in a standard
>XML notation? Many of us do this already, but I suspect that our tagset and
>syntax vary. If we could agree on this - and I don't see this as
>technically difficult - we could help both communities. 

It is not technically difficult--it is, however, practically impossible
except in the most trivial way (a direct transliteration of DTD syntax)
unless it is *explicitly* defined as a base architecture with very clear
rules for specialization. And even then, developing that architecture will
be difficult at best.

The reason it's practically impossible is because getting agreement among a
community of interest as wide and varried as the XML community on a subject
of such importance as how to represent the definitions of document types is
one of the hardest types of things there is to do. There are simply too
many different ways to do it, too many different ways to represent things,
too many interested parties. The degree of expressibility of schemas is
open ended, meaning that any design, to be useful, must be maximally
extensible. Defining extensible languages is hard.

I personally think that trying to define a common markup approach to DTD
representation is a waste of time: the answer is either obvious (Wayne
Wohler did it over 5 years ago) or impossible to achieve consensus on. The
first is not useful compared to the cost of defining and maintaining it,
the second cannot be achieved by any sort of consensus-based approach. So
there's no point in bothering. 

The minimum abstractions needed to define element types are already defined
by the SGML property set--if your schema language can get you to these
abstractions, fine.  

I say let groups define their own schema approaches without bothering to
find too wide of a consensus. If one particular approach gains widespread
acceptance, then fine. If it doesn't, we're no worse off than we were
before, *but* we haven't wasted a huge amount of a scarse resource on a
doomed effort.  This provides opportunities for vendors to distinguish
themselves by providing different types of validation and constraint
support. As long as they always support normal DTD syntax, I see that as a
good thing--if someone like Microsoft produces a product that helps me
create better data repositories, then I'm happy to buy and use it, as long
it accepts and generates normal DTDs with the level of fidelity I require.
But why should I give Microsoft (or anyone else) free engineering support
by being involved in a schema development effort? It doesn't make sense to
me. If they want my help, they can pay me.  I already have what I want and
need and I'm capable of providing for myself if I need more (as is anyone
with a copy of Lark and a Java book).

As long as we have DTD syntax I can ignore or use any schema efforts as I
please, because my ability to use normal DTDs is assured.  The cost of
writing schema-to-DTD-syntax transforms will always be lower than the cost
of participating in wide-scope schema definition efforts.

But maybe I'm just a crank.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

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)