A Line in the Declarative Syntax Sand(Was: XML complexity, namespaces (was WG))

[Sean Mc Grath]

This is an interesting thread.  Many non-tag-minimization
reliables can be put forth as things that SGML "can do" that
XML cannot. Things like data attributes, exclusion exceptions,
internal SDATA entities and so on.

I see SGML and XML at opposite ends of a balanced lever.
On one side we have SGML - high on declarative syntax, low
on home grown code. On the other side we have XML - low on
declarative syntax, high on home grown code.

SGML gives you declarative syntax that can obviate the
need for coding around certain types of data modelling,
content authoring problems.

XML is light on the declarative syntax, leaving more
in the realm of "application specific" implementation
in a programming language.

Ultimately, both views have their place and both
may be "correct" for a given problem domain.

For me, I favour the XML side of the lever. Any
declarative syntax has its limits. It has
been my experience that the limits of SGML's
declarative syntax are quickly reached.[1] Any SGML
system I have ever worked on has a large collection
of ancilliary software to perform validation, data
aggregation, authoring short-cuts that are not
possible with pure SGML syntax.

XML fills a nice 80/20 niche here. 20% of SGML's
declarative syntax is used 80% of the time.
XML draws a line in the sand saying "here is
the most useful 80% in an allround cheaper package. You
will need to write processing software on top
of this but hey!. You would need to do that
with SGML anyway."

Analogies abound. What does it mean to say
you have your data in third normal form
in a relational database? It means that
you have a base data model that is interchangeable
amongst relational database systems. *But* and
it is a big *but*. The rest of the stuff that
makes up the solution is in some application
specific 4GL.

<stance slant="pragmatic">
Declarative syntax does not put bread on
my table. Solutions to business problems
using the beautiful ideas of SGML puts
bread on my table. XML gives me a nice
package that gives me most of what I want
in terms of a robust, simple, implementation
of the SGML philosophy.

I will build software around this package
all day long without ever once missing
an SGML feature. Whats more, I'll do it
in an open, standardized, cheap programming
language that gets the job done fast.[2]

When I go under the bus, I believe my
customers are in a better state than they
would have been if I'd pulled every
obscure SGML declarative syntax trick
in the book.
</stance>

[1] Notations are for me, the classic example
of the limitations of a declarative syntax and
how a declarative syntax feature can subtly
fool you into thinking you have solved a problem
when all you have done is defer it.

You hit, say, a data validation problem that cannot
be solved with SGML syntax alone so you invent
a notation for it. Knock up the declarative
syntax for it. Lovely. It all parses. *However*
the declarative syntax does not do anything. You
still need to implement it as a processing
layer above SGML.

[2] Python http://www.python.org

<Sean uri="http://www.digitome.com/sean.htm"/>



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/ and on CD-ROM/ISBN 981-02-3594-1
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)