[
Lists Home |
Date Index |
Thread Index
]
One might respect it without having to marry it.
Most of what we are saying is Spy Vs Spy: does
the core mean the functions all systems use (so we
are down to elements) or the basic set of services
most people use most of the time? Otherwise, we
are just using our positions to marginalize groups
of users.
The question of importance is, what is an XML
processor normatively guaranteed to deliver as
a service to a calling application?
Rick Jeliffe made some very good points in this
regard, specifically, that we may need to reclassify
processors and document types (not DTDs, the headless
types).
Still, at the bottom of it all is as I said
way back when in another thread: the real issue
here is what is an XML processor? Is there one
or many? Does the spec have to spec only one
or many because that is how profiles will be
instantiated? Should services be declared
as profiles and each gets it's own conforming
processor, or should we have one processor
which can be configured for the services,
or both? Is it syntax based or infoset based?
Never trust a sound engineer who tells you he
can fix it in the mix until he shows you he
can.
len
From: Mike Champion [mailto:mc@xegesis.org]
On Mon, 10 Feb 2003 10:50:19 -0600, Bullard, Claude L (Len)
<clbullar@ingr.com> wrote:
> 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.
Well, yeah. More or less. See below.
>
> So? Are we here to protect a "brand name" or to ensure that XML 1.0,
> 1.1, are inclusive?
I guess I'm suggesting that XML not go the way of SQL, which (AFAIK from
the very interesting XML databases town hall at XML 2002) seemed to value
inclusiveness at the expense of coherence and interoperability. It's much
easier to add features to a "standard" knowing that they won't be
universally implemented than to refactor out the core stuff that really is
universal from the peripheral stuff that is quasi-proprietary (in the case
of SQL) or useful only to specific subgroups (e.g. notations, parameter
entities) or just very problematic in practice (default attribute values
come to mind).
Inclusiveness is politically easy, but saps the real value of
standardization. I want the core stndard to be the intersection of things
that are actually supported and actually work, not the union of all the
things that different people want to use. The intersection of "SOAP
practice" and "Docbook practice" is a subset of "XML 1.x" and I think it
deserves a recognized identity, and some respect :-)
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
