XML-Data: advantages over DTD syntax? (and some wishes)

[Paul Prescod]

> I think the DTDs-as-instances also benefits new users, why should they 
> have to learn two syntaxes instead of one?

Because if the two syntaxes are well chosen for their particular data types
then learning two will be faster than learning one. Let me suggest an analogy:
"Why should I learn these mathematical symbols when this can all be described
in English." Because you only benefit from the English description *in the
very short term*.

> One of the first questions which entered my mind when seeing a DTD for 
> the first time was:
> "Why didn't they code this using SGML, why a completely separate syntax 
> for this?".

I asked this myself. It is a natural question. I also asked this the first
time I saw a regular expression. "Why does this bit of code look so different
from the rest of the program?" It turns out that there was a good reason.
I also asked that the first time I saw a functional language. It turns
out that there was a good reason there too. We should fight forever to avoid
difference for differences sake, but not difference for readability's 
sake.

> I assume most people today won't edit DTDs (either today's version or 
> XML-Data or similar versions) in the "raw" text format. They will of 
> course use tools, visualizing the hierarchy (XML-Data's 
> extends/implements), selecting values from comboboxes etc.

If this is the case then the syntax is irrelevant for those people and
they are thus not relevant to the discussion of syntax.

> I think some advanced functionality is very difficult with todays DTD's, 
> as (to my very limited SGML-knowledge) many things are 
> "simulated/hacked" by using parameter entities.
> I think this parameter entity (macro) approach is much less "semantic", 
> and is much more difficult for a tool to handle.

No argument. But now you are complaining about the features available in
DTDs and not with the syntax. You must invent the features either way.

> Mr. Prescod also wrote:
> -------
> "Of course particular DTDs-as-instances proposals may have other =
> benefits,
> but those benefits could as easily be added to DTD syntax as to some
> new syntax."
> </>
> 
> Adding new constructions to DTD syntax would force parser builders to 
> update the "lower parts" of their parsers/lexers, but in a 
> DTD-as-instances version the upgrade would only affect the "semantic" 
> part of the engine.

I haven't disputed the argument that DTDs as implemnentors make life easier
for implementors. I just find specious the argument that it makes life 
directly easier for users. It will only (perhaps) make user's lives easier
if more implementors adopt it because it makes their lives easier. But I
do not find it better pedagogically or "type-o-graphically". I am already
dreading my future classes when I will have to teach this to people who
are already inclined to confuse levels (mix up elements and element types
etc.)

> And more importantly, it would be easier to communicate to users that 
> "now this (DTD)element has gotten this new attribute, which means X 
> etc", instead of having to introduce the new syntax for DTD-encoding and 
> then explaining it's semantics. (This is why we like SGML/XML in the 
> first place, not needing to use more or less unstandard syntactic 
> encodings)

And now we must explain to users that when we say "this element has got
a new attribute, we don't actually mean *this element*", but the element
type described this element.

 Paul Prescod


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)