RE: My summary of the XML names threads

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

That's reasonable.  SGML-capable companies 
exist that can satisfy requirements based 
on SGML competence.  These companies 
based on that competence are fully 
capable of handling XML as well given that 
XML is a conforming subset.  The reverse 
is not true for XML-only companies but that 
is, as you indicate, by their choice.  

As Tim Bray said, 

"Lately, I have also been explaining that there is an SGML starter-kit 
called XML, which is small, lightweight (I wave a printout of
the draft spec at them), easy to understand, and designed to work on 
the web.  But you still get data safety and constrained-authoring 
because it's SGML."

I've no problem with that.  Alternative SGML derivatives that 
are more capable and also designed to work on the web are 
always possible, do exist, and perhaps for some company or group wishing to
get 
into a more competitive position, realistic.  The XML tools wouldn't 
work for these formats but the XML formats would work for those tools.  

So only the non-SGML tool vendors and non-SGML developers lose.  

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: XML Everywhere [mailto:host@xmleverywhere.com]

This is the XML-dev list, not
the SGML-dev list.  The vast majority
of us, although not as vocal, 
won't go back to SGML, even
if it solves every last encoding issue,
bakes bread, and makes a mean martini.