Re: Recent ERB votes
> > 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
> 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
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.
> 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.
ps: out of town from tonight until next friday. y'all have fun.