[
Lists Home |
Date Index |
Thread Index
]
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: Linda van den Brink <lvdbrink@baan.nl>,"'xml-dev@lists.xml.org'" <xml-dev@lists.xml.org>
- Date: Tue, 14 Nov 2000 11:17:20 -0600
Or None Of The Above.
Use DTDs if you don't need extensive datatypes, derivation
of types within a schema, precision in defining ranges,
or you dislike the cognitive overhead of element:Element,
schema:Schema. If you want to process declarations using
the same tools used for the instances of declarations,
use schema or something like XDR if you want a simpler
validation.
But don't forget the well-formed option (none of the above).
Consider the environment (application to application routing)
and if you need an XML Schema or DTD to make that work.
It isn't database vs document. To usefully apply
XML, consider your existing technology.
For example, namespaces can be useful for keeping up with
which table is a source for a view as defined
in a SQL query, but relational schemas
don't share namespaces. An XML schema defining
a mixed namespace is doing the work a relational
programmer does in the query syntax of SQL.
While one can use the namespace to prevent
name collisions, in practice, there are other
ways to do this. Names collide in aggregates (views)
and in relational systems, views are temporary,
so there isn't a need to declare the constraints
for a view in other than procedural terms.
In SQL, the query is used JIT to alias the name
for the scope of the operation (select, insert, delete,
update, etc.). The kind of reuse described in the
XML Primer may not prove to be all that useful
in some operational contexts.
So you can consider the environment and what
kind of process you want to support not simply
the types of artifacts (documents, data, etc).
If a relational schema is the record of authority for
transactions, your use of the XML schema or a DTD
can be safely limited to simple applications but
your ability to safely control this and communicate
it to other trading partners is limited.
If on the other hand, you have an open system in
which dissipative effects brought on by decentralized
control (lots of players, no overall controlling
authority, new players entering at
irregular intervals - an open dynamic web), then
you have the problem of not being able to easily
scope local decisions that affect global decisions
(aggregate rippling). I can see how using
SOAP could lead to some interesting problems.
Think of the current American election
dilemma: lots of little different voting systems all
contributing to a single decision. It works fine
until you get a close vote and then the uneven
precision brought on by lots of different rules in
different political scopes is exposed. SNAFU.
A system of communication that mixes DTDs,
Schemas, etc. could be unmanageable unless
noise is smoothed at the interfaces, and in that
case, local decision scope is not exposed.
DTDs won't go away soon but fewer and fewer
developers will use them. I expect XML Schemas
to become the dominant instrument as soon as
the tool support is ubiquitous and the practice
is established. Today we are still wrestling
with the spec, the lack of clarity in the
explanations, and the mindFUD of learning how
to use them. I expect the Schematron work,
RELAX, etc to contribute to the next version
of XML Schema. OTOH, the insertion of the
technology will be slow and tedious and during that
time frame, niches will become entrenched.
Len
http://www.mp3.com/LenBullard
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
|