[
Lists Home |
Date Index |
Thread Index
]
It boils down to the existence of the common subset.
That is worth identifying if it indeed exists and
can satisfy a sufficiently large enough user base
to make it worth the hassle of knowing in the code
when a different parser implementation is to be
called. Remember, every code fork is a set of
costs not just to performance but to every aspect
of system support.
Doing this just to support SOAP or
any single application is not worth it. Period.
Doing it and then having the SOAP or other
application community come back in six months
and saying it just isn't good enough for their
application isn't worth it. Period.
That said, provide good numbers and it will be
adopted by the W3C. They have already initiated
the exploration of this based on the numerous
e-mail discussions, internal requests and so
forth. So I don't see any kind of conflict
with the W3C agenda and I don't expect this
to be an effort created in the wild.
This is about deciding what set of features
can always be relied upon from an XML processor.
Whatever the *subset* is, it is either application
-specific, meaning it doesn't need to be XML or
can be application-specified, or it is a common
subset that any XML application processor can
use. So far, no compelling arguments for it
have been presented except in the case for
XML documents being requested at a high frequency
where the setup and tear down times are significant
to the requesting application.
These tend to be exclusively network messaging
applications. If the subset is to be a network
messaging XML, then identified as such, it must
support the entire network messaging XML community,
and it must not conflict with or be overcome by
an XML binary.
len
From: Jeff Lowery [mailto:Jeff.Lowery@creo.com]
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> And yes, I see the subsetting as a good thing.
It boils down to the question of the existence of one common subset that
makes sense for a significant class of applications. If both the class of
application and the subset of XML can be cleanly identified, then not only
will the subset gain wide acceptance, it will attain a branding outside that
of the W3C. A sufficiently successful brand of XML will eventually develop
an agenda that comes into direct conflict with W3C's.
That's not necessarily a disaster: the best case is that the W3C finally
gets around to embracing a subset by necessity in order to avoid two
separate incarnations of XMLish language trees. In the worst case, the two
trees become irrevocably irreconciled and if the domains divide along the
borders of data and documents, that'll be a chasm in mighty need of a
bridge.
|
