XML-Data: advantages over DTD syntax?

[Rick Jelliffe]

> From: len bullard <cbullard at hiwaay.net>
 
> Anyway, without responding to the details of our exchange, you 
> miss the point:  Does XML-Data offer more functionality?  If 
> so, then good.  If not, then why bother?  I thought it did, 
> but I could be wrong.
 
Someone asked me to state more clearly some deficiencies I see in
XML-data.  

Let me again preface by saying that this is only with
the current version of XML-data, not with its intent.  
However, let no-one be confused that we will be left
with a whole additional standard that in a large part replicates
SGML, and for which particular gurus will be needed, if they
do find things that XML-data can do that SGML cannot.

1) Non-standardness: XML-data is proprietary.

2) Not generalized: Presumably XML-data is being developed
to solve some real problem (they wouldn't be paying someone
to come up with good ideas that just sound good, would they?). 
Since we do not have access to the problems that XML-data is
supposed to solve, we have no way of testing whether it does
indeed provide a good generalized approach that is significantly
better or more flexible than SGML.

(Reading between the lines, I think XML-data may be targeted
at retrofitting slack HTML documents with inline generalized
markup.  In other words, it probably has the assumption that
we cannot use DTDs, because the target data is so slack that
no DTD is possible. So they need something that can just
markup parts of the data. This is an interesting problem,
and one that ISO 8879 clearly does not address, except by 
external HyTime/XLL pointers into data, I guess.

Can anyone in the XML-data conspiracy confirm this? It is
a wild guess :-) 

3) Not markup: The approach of not separating out what
can be known about data ahead of time (or for every 
instance) from the details of the particular instance
is justified under the slogan "all metadata is data",
which avoids the question "should data that has different
significance be marked-up differently?".

XML-data removes this difference between declarations and
markup (so everything is a declaration, in a way). This
has a major impact on what can be known about a document
type for system builders: it prevents "precompiled" applications.
If the XML-data declaration-elements get a flag or a something
to say "this can be pre-compiled" then you just return
to having a special markup convention, just like ISO 8879
declarations.

4) Not a human readable-language.  Contend models are simple,
terse and convenient.  Of course, diagrams etc are simpler.
But XML-data's verbosity will make reading any kind of 
lengthy DTD more complicated.

For some other particular technical issues:

a) ANY is not defined. Is the same as SGML's ANY? Is it
an error if you extend the content model of an ANY base
element?

b) Order of extended element content models is not clear.
If I derive a "cat" element type from "animal" element type
and say it can also contain a "purr-volume" element type, 
is there any way of constraining where this element
can go?  Ordering information in content models is vital
for many processing application, and for integrity.
Can such additional element types go anywhere, or only
at the end, or where.

c) Is there anyway of preventing derived elements from
adding additional tags in particular places?  

I think one weakness in current SGML is the lack of a
#ANY  keyword for use inside content models, e.g.
 <!ELEMENT cat (purr-volume, #ANY?, paws+)>
I do think this is a much better solution than
anything XML-data currently proposes.  XML-data
really does not seem to have thought of content models
as being a tool to manage information (i.e. to frustrate
well-intentioned users from adding innappropriate elements in
mission-critical places), just to describe it.



Rick Jelliffe  

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)