Re: Recent ERB votes

[Jon Bosak]

> > The primary use of XML is to convey structured information
> > from SGML databases to Web applications.  The batch processes that I
> > used to generate the Shakespeare and Religion collections are actually
> > much closer in spirit to the problem domain that XML is primarily
> > designed to address than anything having to do with native authoring.


> Again, your answer is not a surprise to me, but I think it is useful
> to see it in print.  I have sensed a lot of people trying to give
> lip service to the claim that XML is a subset of SGML--at least in
> spirit if not in fact--and it's refreshing to have you admit that
> this is not your intent.  It's not your intention that the base of
> existing SGML authoring tools will handle XML.


> "Natural SGML" may well be some subset that omits a lot of esoterica.
> However, XML as being defined now will require new tools and will force
> new decisions upon potential users that will cause extra confusion as
> they try to figure out what to do with their data.  Whether this ends
> up being good for the users is still an open question.

It isn't good for the existing SGML users and vendors.  It is an 
alternative to SGML, not a subset.  That is bad news.

> > I will repeat the point that I want to make sure doesn't get lost
> > here: the XML spec does not favor HTML legacy data over SGML legacy
> > data; quite the contrary.

Pardon, but only one existing application of SGML is contributing 
to a tag pool, so far.  I understand what political suicide is.
I suggest if that is what you want to avoid, retain <e> and 
state that the added complexity of the parser in XML is to 
retain compatibility with existing SGML applications and systems
such as Netscape and Microsoft IE because these are the only 
Shogun's that will compel you to ritual suicide.  

Political suicide allows one to reincarnate.  Clinton does 
it regularly.
> I'm not sure a comparison to HTML is of as much interest for me as the
> comparison between XML and SGML legacy, both in terms of legacy
> instances as well as legacy DTDs, information modeling, and processes.

It is for me because I generate information in that notation.  However, 
I also use the others and get them for conversion into hypermedia.
XML is *for me* a legal target for simplifying the systems and markup 
required for that.  SGML server to HTML client is just one particular 
technical approach.  Using rewrite languages such as PERL to create 
markup products is another.  XML was *I thought* to be a simplified 
SGML that works in the *current* network environment and enables
products to 
be created and interoperated at lower costs by reducing the requirements 
for absolute two way fidelity.   In other words, give up some legal 
and abnormal exception handling; get back the ability to build and 
choose structures.  But, still, generalized validatible markup.  

The requirements that are compelling beyond that are the markup 
structures and properties which are used in the interface processes, 
e.g, hyperlink types.  These we share because it makes the net go.

Then stylesheets, because fidelity is always a requirement.
What the stylesheet is used for vis a vis protocols, operations, 
etc, is a more difficult question.

> There is a huge and important customer base that has a whole lot
> invested in "legacy" SGML.  I suspect that only a very small portion of
> the total investment is, for example, based on the various minimization
> techniques of 8879, so I'm happy to see them tossed.  But I suspect,
> for example, about 99% of the investment is built on assumptions that
> there are EMPTY elements.

If my sample is significant, I agree.

> Insofar as XML is just "a subset of SGML without the cruft" then I
> don't have as much of the marketing problem I describe above.  Maybe
> if all the vendors hop to it and add "XML-mode" and "Convert to
> XML/convert from XML" options in their tools, then we can minimize
> the effect of the market confusion.

Maybe, but if the cost of converting existing legacy to XML is 
greater than the cost to kluge a way to move SGML onto the 
Internet even at the risk of monkey-wrenching HTTP, we will do it.
So far, nothing I see makes me think we even have to do that. 
All we have to do is be careful about what features we use and 
do it.  Interoperability with other vendors choices can be an 
issue worked out in the marketplace, just as it is being done 
now by the HTML vendors. What I was hoping for from this group 
was a serious effort to avoid a competition between XML on 
The Web and SGML On The Web.

Seems counterproductive.
> Meanwhile, it'll be interesting to see how all this plays in Boston
> when it gets more into the hands of community at large.

I'd love to see that, but I will be in Orlando trying to 
convince members of my corporation that we should be targeting 
XML for IETM products if possible.  If not, no sale.  We 
already know how to use SGML for that and the Web and we already 
know which features of SGML not to use for our purposes.

XML is a chance to cooperate.  Pardon Jon and members of the 
ERB:  it is yours to vote on the content of the spec.  It is 
ours to implement what we choose to implement.  The investment 
of the SGML tool vendors is important.  I doubt that you are
going to have as quick a success with your other romances.

len bullard

ps:  out of town from tonight until next friday.  y'all have fun.