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

[David Megginson]

Rick Jelliffe writes:

 > Surely the equivalent XML to the SGML examples given is really:
 > 
 >     <doc>
 >      <photodef id="p1" href="pic1.png" notation="text/png" width="300"
 >     height="200"
 >     depth="16"
 >     type="I point to some object called an NDATA entity"
 >     content-model="I must be empty"
 >     addressing="don't count me as an element when doing treeloc" />
 >      <photo href="#p1" />
 >     </doc>
 > 
 > (and perhaps the photo element should not be  simple link)
 >
 > The information modelled does not only include the elements and
 > attributes but also the structure, and the fact that an entity is
 > labelled as an entity, which have different addressing rules. In the
 > absense of XML having conventions for the last three attributes, I dont
 > think one can say that one can model everying that SGML models using
 > XML.

Rick, you're still pointing to implementation details rather than
abstract modelling.  Try to express the question in terms of the thing 
being modelled -- for example, at a project meeting, the system
architect might ask the following question:

  Can SGML and XML both model a reference to a photograph, providing
  the width, height, and colour depth?

The answer, of course, is 'yes'.  At this point, the system architect
drops out of the discussion and starts playing Tetris on her Palm
Pilot.

Next, someone asks whether there's a substantial difference in the
time and cost for implementation and maintenance.  Both SGML and XML
can declare the object in a single place as an external NDATA entity
or upon each reference as an HREF attribute, and both SGML and XML can
provide the type information explicitly in a single place through a
notation or upon each reference through a MIMETYPE attribute, or allow
the application to determine the type through the transfer protocol
(i.e. HTTP), file extension, magic patterns at the start, etc.

However, the SGML guru points out that information about the graphic's
size (if needed) can be expressed in SGML in a single place using data
attributes when the entity is declared, while in XML it needs to be
repeated in attributes for each reference.  The XML zealot mentions
that you could use a single XML element to model the photograph as an
independent object, and a short and confusing debate ensues with the
XML specialist and a couple of data-modelling specialists taking up
one side, and the SGML guru and a couple of document-modelling
specialists taking up the other, while the rest of the room falls into 
a stupor.

Suddenly, the project manager jolts himself awake and asks what the
disadvantage is to giving the size information for each reference
rather than once in the declaration, and whether doing so will delay
the project or cause serious headaches when the project migrates to V2
in the fall.

The SGML guru declares that it's always better to maintain the
information in a single place rather than repeating it, because if the
information changes, it's all in one place and can be accessed easily.

The XML zealot argues that you can do the same thing by treating the
picture as a first-class object, modelled with elements.  The SGML
zealot cuts in and says that that will mess up HyTime addressing, and
at the mention of the word 'HyTime' a sudden panic grips the room,
until the XML zealot kindly points out that the same thing might apply
to XPointer.

There is a second, brief religious war between the SGML guru and the
XML zealot about whether the photograph is a declaration that belongs
in the prolog or an object that should be modelled in the document
element (again, the data-modelling specialists and the
document-modelling specialists take sides), but the meeting is going
on too long and it's becoming obvious to everyone except the SGML and
XML people that the differences aren't really important enough to have
a measurable effect on the project.

Just to be certain, though, the project manager cuts off the debate by
asking how often the same picture will appear in a single document.
The graphic designer mentions repeated graphical elements like
specialised bullets, icons in the page headers, etc., but the SGML
guru and the XML zealot both shout her down by saying that that kind
of thing is handled by the stylesheet.  

The system architect (who has finished Tetris) then declares that
information about the photograph's size, type, etc. should be stored
in a relational database, where it can be easily maintained and
updated, and that the SGML or XML will simply contain a unique
identifier that can be used to generate a primary key for a database
lookup.

Every else at the meeting except for the markup specialists nods
vigorous agreement, the meeting breaks up, and they all rush for the
coffee machine or washrooms, except for the SGML guru and the XML
zealot -- they stay at the table, arguing whether the unique
identifier for the database lookup should be a formal public
identifier or a URI.....


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)