Re: XML interchange

Peter Flynn wrote:
> 
> At 16:47 12/03/97 -0600, Len Bullard wrote:
> >Paul Grosso wrote:
> >>
> >> Several of us were talking yesterday at the GCA XML conference
> >> about the fact that one of the biggest problems with SGML is
> >> still with what's supposed to be one of its key goals: interchange.
> >
> >With the caveat that it is actually easy to interchange an SGML
> >document;  it is hard to interchange all the other pieces needed
> >by the application that processes it.  It isn't hard to package it;
> >it's hard to know what goes in the package.
> 
> Couldn't some parser author add an option to spit out a list of
> the filenames used in parsing an instance? Say nsgmls -Z produces
> 
>    teisgml.dec
>    foo.sgml
>    teifpi2.ent
>    ...
>    tei2.dtd
>    teicore2.dtd
>    ...
>    isolat1.ent
> 
> (complete paths where relevant) in a form you could pipe into tar or zip?
> Or a list of the FPIs instead/as well?

Yes that is possible.  That wasn't my point although it is an 
excellent suggestion.  

We could not say before what a stylesheet was.
We could not guarantee what would be in a catalog.  
We could not get two experts to agree on what a hyperlink should have in
it. 
(ok... the last bit is still a problem, but has boundaries now).

The problem has not been a technical one but one 
in which there have been many competing and variant approaches to 
the stylesheets, the links, the catalogs, etc.

We already have systems for SGML based on strongly typed links, 
automated stylesheets, well-formed content, etc.  What we have never 
had before was agreements among ourselves that stayed in place 
long enough to establish common practice.   XML is where the SGML 
community has been working these things out. Noisy, yes; productive,
very much so.

Certainly we have been an arbitrary lot at times, but the more
compelling 
problem has been we have been driven by other strong forces.  The 
remark by Paula Angerstein, "well, more charity work for DoD" always 
sticks in my mind.   American SGML was hard driven by CALS for a long 
time.  That was a very big bureaucracy.  It resulted in some 
excellent work, but it tended toward standard DTDs and that wasn't 
enough.  Further, it was driven by requirements that weren't 
always generalizable.  The IETM standards are a good example.
It was driven by overconcern for print and presentation, and 
sometimes, by a lack of concern for that.

What is different here is that XML is happening because 
WE wish it to.  Not customers, not the government, not academic 
requirements, not the Web, none of these: this WG is made up of 
committed SGML professionals: top dogs, creme de la creme.  We are 
the ones who care, and we are doing this using a media that allows 
us to come together daily, hourly, sometimes minute to minute.

Where it may be contentious, it is our contention.  Where it may 
be successful, it is our success.  Don't forget that.  To paraphrase  
what the man says at the end of the X-Files episodes, "We made this."
It isn't a revolution:  it is an emergence.  SGML has been 
like watching an elephant give birth:  long pregnancy but a big baby.

What Paul has suggested is very right.  There is another piece of this 
that has to be done, so why we are under the house fixing the plumbing, 
let's go ahead and tighten up the pipes. Nice thing about internet
lists; 
at the end of the week, no one goes home.

len

Received on Thursday, 13 March 1997 15:36:02 UTC