[
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
later.
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.
len
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".
|
