OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: DTDs, W3 XML Schema, RELAX, or Schematron?

[ 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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS