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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] SML: Second Try

[ Lists Home | Date Index | Thread Index ]

It's pretty easy to discriminate SOAP 
from DOCBOOK.  Read the specs for the 
applications.  Don't make the spec for 
the metalanguage take on that role. Who 
pounded entities and DTDs into SOAP? 
Not moi.  Instead, they sensibly excluded 
them just as the IADS group sensibly 
excluded DTDs and used stylesheets for 
SGML without needing XML to tell them 
how to do well-formedness.  The only 
rub was having SGML wonks beat them 
up for doing in 1991 what the rest 
of the world would call XML six years 

So?  Are the XMLers beating up the 
SOAP folks?  No.  It seems the other 
way around this time.

The rest of what you are saying is 
more of the same:  fear of the wild. 
That is, if we don't make an official 
subset, subsets will grow willy-nilly. 

So?  Are we here to protect a "brand name" 
or to ensure that XML 1.0, 1.1, are inclusive?

I don't dispute that a subset can be devised. 
I think the XML-SW is such a device.  I haven't 
seen a requirement for it other than tidy 
documentation of some intersection of 
common practice which if normative, gives 
a bit to some, but takes a bit from everyone. 
The intersection that is broken are things 
like ids.  That is, it is as we have known 
for years not possible to completely separate 
processing from declaration.  Not new news.

Sure, the same was said for SGML and in the 
large it was true.  Easier to understand is 
easier to sell.  But XML is already implemented 
widely so why do this exercise again?

SGML had features that were designed for 
an era of less convergence.  It was also more 
author friendly, but at the cost of 
tool complexity thus, tool cost.  Authors 
gave up some conveniences (eg, minimization) 
to make it more attractive to a narrow but 
influential group:  programmers.  The 
trade-off created an environment that 
produced more and cheaper tools.  I don't 
see that tradeoff happening here.  I see 
a narrow application trying to make its 
own performance an issue for every user.

That is, as David Durand used to remind us, 
an issue of implementation, not design.


From: Mike Champion [mailto:mc@xegesis.org]

On Mon, 10 Feb 2003 09:57:26 -0600, Bullard, Claude L (Len) 
<clbullar@ingr.com> wrote:

> SOAP works.  What about XML 1.0 keeps SOAP from working?
> XML binaries are working.  What about XML 1.0 prevents that?

Nothing!  Web services don't need anything different from XML, they just 
took what they needed.  XML binary users don't care that what they're doing 
is anathema to some XML geeks.  IMHO, XML needs to be concerned about these 
things for its own sake, not the sake of diverse communities of users.

The question is whether "XML" will mean anything as a brand/label after 
another 5 years of this success.  It might become about as meaningful as 
"LISP" or "SQL" (without qualifiers) -- a generic term describing a general 
approach, but not anything that interoperates out of the box.  The way 
forward that I suggest is continuous refactoring to keep the Core "core" 
and the de-facto optional parts separated.  I don't want the data-heads to 
drive static typing into the core to the detriment of the docheads, but 
neither do I want the dochead stuff such as entities to be inflicted on the 
data-heads now that the costs are becoming apparent.  The SOAP people 
aren't harmed by simply ignoring DTDs, but XML is harmed if there is no 
formal way to distinguish "XML as practiced by SOAP" from "XML as practiced 
by Docbook".


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS