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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


At 12:25 28-06-2001, Rod Davison wrote:
>As I understand it, there are two distinct activities that occur on the web
>which I see being lumped together in these discussions.  The first activity
>is browsing and the second activity is the exchange of data between
>applications over the web/Internet/intranet.

Browsing is the exchange of data between applications over a network - one 
of which happens to be a browser.

>SGML is designed for documention.

More precisely, for documents.

>In this usage
>SGML is superior to XML, and it makes sense that we should have SGML browsers
>because this gives enterprises a way to... well ... browse ... their
>repositories of SGML documentation.

I'm not sure I follow this.  The chief difference between SGML and XML is 
optional features to make hand-entry of data easier by leaving out 
redundant information and allowing abbreviations.  It's not clear how this 
makes browsing easier.

>Which in many domains is considerable --
>millions of pages in aerospace, and I'm sure the Aussie Hansard is
>considerably more.  So, why on earth would we want to abandon SGML browsers
>for XML browsers?

Because there are more.  Regardless of the technical barriers or lack 
thereof, the reality is that SGML was not being implemented in the 
mainstream.  XML is.  (Whether it'll reach reliable browsable status is 
another question.)

>XML is designed for data transer, or at least that is my understanding,

That is incorrect.  XML was expressly designed to enable SGML on the 
Web.  Full stop.

What happened was that because of the simplified syntax, a lot of people 
who had ignored (or even disdained) SGML jumped on XML for transferring all 
kinds of data.  SGML proponents had been pointing out its flexibility for 
years; see Goldfarb's discussion of the blind men and the elephant in _The 
SGML Handbook_.  But the ease of entry to XML made that practical.

There's a perceived (and, to my mind, false) dichotomy between "documents" 
and "data".  All documents are data; all data can be expressed as 
documents.  The main difference is between regular, or repetitive data, and 
irregular data.  Many tools are useful for both domains.

>Remember the SGML was not developed as a internet data exchange tool -- at
>the time there was also a Berlin Wall, Watergate was still a hot topic and
>Disco ruled.  SGML is industrial strength and more than we need for this data
>transfer, especially when we have to write those applications.  XML was
>designed as a data exchange tool, not as a competitor to SGML.

It was designed to *be* SGML, to get people to play our game.  It worked, 
though not entirely in the way that the originators like Jon Bosak intended.

Logically and functionally, SGML and XML are identical.  The difference is 
that SGML lets you represent the information in more different ways, and 
that makes it harder to understand what you're getting.  That kept a lot of 
people away from SGML until recently.

Christopher R. Maden, XML Consultant
DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training
<URL: http://crism.maden.org/consulting/ >
PGP Fingerprint: BBA6 4085 DED0 E176 D6D4  5DFC AC52 F825 AFEC 58DA