W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > April 1997

Re: STEP/XML Presentation to WWW6 Workshop

From: Steven R. Newcomb <srn@techno.com>
Date: Thu, 10 Apr 1997 15:37:06 -0400
Message-Id: <199704101937.PAA01385@bruno.techno.com>
To: daniel.rivers-moore@flps.co.uk, DanielFLPS@aol.com
CC: w3c-sgml-wg@w3.org

[Daniel Rivers-Moore (daniel.rivers-moore@flps.co.uk):]

>            =====================================
>            XML AS A VEHICLE FOR DATA INTERCHANGE
>            =====================================
>     1997,  RivCom, Lotmead Business Village, Swindon SN4 0UY, UK
>                         All rights reserved
>     Permission to reuse this text for any non-commercial purpose 
> is hereby granted, provided this copyright notice is reproduced in full

...

> It has been suggested within the STEP community that tagged text could
> be used as an interchange format between STEP-compliant databases, and
> that one way to achieve this would be through a standard mapping to
> and from SGML. To make this SGML interchange format useful would also
> require that there be a universal addressing system - i.e. a way of
> uniquely addressing (world-wide) any item in a STEP database, possibly
> through the use of HyTime links.
> 
> Will XML provide a sufficiently robust and rich interchange medium for
> the kind of data exchange which STEP requires? For it to do so would
> require a standard means of expressing the entire data model of a
> STEP-compliant data warehouse, together with a subset of its contents,
> in the form of valid (or at least well-formed) XML. The interchange
> package would presumably need to include appropriate DTDs (if any),
> link files, and a robust universal addressing mechanism. The inclusion
> of stylesheets would presumably be optional, depending on whether, in
> addition to data interchange, the contents of the package were
> intended for display.
> 
> Will XML be able to do all of this? If the Web is to be used to share
> or exchange STEP data, and if XML aspires to be the preferred way to
> use SGML on the Web, then it will need to rise to this challenge.

XML is just fine as a delivery format for the Web, and, as such, it
may even be suitable as the source code form of some kinds of assets,
just as HTML is.  But XML is not SGML.  It would be a grave disservice
to promote the idea that XML is a suitable language for the source
code of valuable information assets, or for interchanging such
valuable assets.

One thing that is currently lacking is a clear statement of what XML
is NOT.  Everybody knows XML offers important simplifying advantages
over SGML for implementers.  But few people are saying what advantages
SGML has over XML.  There are many such advantages, and at least some
of them will be vital to STEP information asset owners in managing and
interchanging the source code of their assets.

XML is like Cinderella's glass slipper.  Ugly information management
problems, like Cinderella's ugly stepsisters, will have to amputate
portions of themselves in order to fit into the XML solution.  Such
amputation will only make them uglier, and crippled, too.  It will
also make a bloody mess of XML, and cause considerable pain and
anguish.

The fact that Mr. Rivers-Moore is asking whether XML is strong enough
to provide "universal addressing" prompts me to reply, "I sincerely
hope nobody will say `Yes'."  It is true that XML provides linking and
addressing facilities that are (small) subsets of those provided by
HyTime.  But if XML provides "universal" addressing, then by
definition it provides all the addressing facilities of HyTime.  I
don't think anyone who is implementing XML wants to implement all of
HyTime's addressing facilities.  If XML does NOT provide "universal
addressing", then we must say so, and we should refer people who need
more addressing power to HyTime.  The same situation applies to
linking; HyTime's linking facilities are much larger, much more
powerful, and much harder to implement than XML's.  And that's just as
it should be!  XML is designed to be easy and useful in the Web
environment, whereas both HyTime and SGML are designed to be
unstoppably powerful and useful in all environments.

It is essential to the protection of the value of XML that we
understand and explain clearly what it does not do, and when SGML (and
HyTime) should be used instead.  Otherwise, XML will undergo
feature-creep, and the beauty of its hard-won minimality -- the small
size, light weight, and transparency of the glass slipper -- will be
lost.

Now in answer to Daniel's question:

> Will XML be able to do all of this? If the Web is to be used to share
> or exchange STEP data, and if XML aspires to be the preferred way to
> use SGML on the Web, then it will need to rise to this challenge.

I hope XML will resist the temptation to rise to such a huge
challenge, because its usefulness and beauty will surely be lost in
the attempt.  It would lose its simplicity/lightness advantage over
SGML.  Furthermore, I see many advantages (and no disadvantages) in
using SGML/HyTime for STEP source data.  It is wildly unlikely that
interactions with STEP source data can usefully be supported by
generic XML browsers anyway.  There are far too many specialized
semantics.  And if you can't usefully interact with STEP source code
using a generic XML browser, what's the advantage of using XML to
interchange STEP data?

Providing access to STEP data on the Web is one thing; this can and
should be done using XML.  Interchanging STEP data is a completely
different thing.  If I wanted to receive some STEP data in an
interchangeable form, I certainly would ask for the source code
itself, rather than the result of filtering such source code for
Web-style delivery.  XML is not, and should not try to be, the right
solution for STEP sources, or for lots of other kinds of information
asset sources, either.

             Steven R. Newcomb   President
         voice +1 716 271 0796   TechnoTeacher, Inc.
           fax +1 716 271 0129   (courier: 23-2 Clover Park,
      Internet: srn@techno.com    Rochester NY 14618)
           FTP: ftp.techno.com   P.O. Box 23795
    WWW: http://www.techno.com   Rochester, NY 14692-3795 USA
Received on Thursday, 10 April 1997 15:47:01 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:04:24 EDT