Lists Home |
Date Index |
- From: David Megginson <email@example.com>
- To: "XML Developers' List" <firstname.lastname@example.org>
- Date: Tue, 23 Mar 1999 07:05:50 -0500 (EST)
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 [
Here's a typical XML way to do it (also works in SGML):
<!DOCTYPE doc SYSTEM "mydoc.dtd">
<photo href="pic1.png" width="300" height="200" depth="16"/>
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 Megginson email@example.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)