OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   re: A Line in the Declarative Syntax Sand(Was: XML complexity, namespace

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <david@megginson.com>
  • To: "XML Developers' List" <xml-dev@ic.ac.uk>
  • 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 "....">
      width NUMBER #IMPLIED
      height NUMBER #IMPLIED
      depth NUMBER #IMPLIED>
    <!ENTITY pic1 SYSTEM "pic1.png" NDATA png [

     <photo src=pic1>

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

    <?xml version="1.0"?>

    <!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                 david@megginson.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS