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

[David Megginson]

Sean Mc Grath writes:

 > 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 think that I agree with what Sean is saying here and later in the
message -- think of *what* you can represent rather than *how* you
represent it.  For instance, let's take a graphic where we want to
provide the width, height, and colour depth to the processor.  Here's
a typical, declaration-heavy (Sean's term) SGML way to do it (except
that a hard-core SGMLie would use public IDs):

  <!DOCTYPE doc SYSTEM "mydoc.dtd" [
    <!NOTATION png PUBLIC "....">
    <!ATTLIST #NOTATION pgn
      width NUMBER #IMPLIED
      height NUMBER #IMPLIED
      depth NUMBER #IMPLIED>
    <!ENTITY pic1 SYSTEM "pic1.png" NDATA png [
      width=300
      height=200
      depth=16
    ]>

    <doc>
     <photo src=pic1>
    </doc>

Here's a typical XML way to do it (also works in SGML):

    <?xml version="1.0"?>

    <!DOCTYPE doc SYSTEM "mydoc.dtd">

    <doc>
     <photo href="pic1.png" width="300" height="200" depth="16"/>
    </doc>

You're modelling exactly the same information about the picture in
both -- data attributes provide an alternative mechanism for modelling 
the information, but they do not allow you to represent anything that
you could not represent without them.

 > 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.

Right -- the question is not whether there is a benefit to continuing
to develop the two in parallel, but whether the benefit will outweight
the cost.  We'll see what the market decides over the next few years.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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)