[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Debating "civil disobedience" against overlycomplicatedspecs
- From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- To: xml-dev@lists.xml.org
- Date: Mon, 24 Sep 2001 16:24:19 -0400
> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xyzfind.com]
> Sent: Monday, September 24, 2001 3:36 PM
> To: Sean McGrath; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Debating "civil disobedience" against
> overlycomplicatedspecs
>
>
> I was referring to precedents of specification rather than precedents of
> implementations' conformance levels. SOAP is the first
> specification I've heard of that treats DOCTYPE declarations as errors.
Are
> there any other specifications that do this?
I don't know of any. But that's why I used the term "civil disobedience" to
describe what Electric XML does in its non-standard API, and various
implementations of other specs seems to be doing quietly: ignoring the stuff
in the specs that makes life complicated for ordinary users who don't
generally care about notations, unparsed entities, attribute types,
namespace complexities, and such. In other words, they're not fighting the
"laws" (complex specs) in "Congress" (the W3C), they're simply ignoring the
details they don't like.
There seem to be two rational ways that the XML community (e.g., the folks
on this list) could address this. The obvious one would be to try to shame
the implementers into doing the right thing, for example by volunteering to
write and perform conformance tests and publicize the results. A corollary
would probably be that you should lobby the SOAP WG into allowing PIs and
DOCTYPE declarations (and the whole tangled mass of stuff that DTDs bring to
the party) in SOAP messages.
The other approach would be to lobby the W3C for a clean way to define XML
feature profiles that applications could use to specify the contract between
producers and consumers of data -- not just the elements, attributes, and
values, but the other stuff such as acceptability of DTD internal subsets,
CDATA sections, PIs, and various namespace declaration configurations. This
would make the SOAP debate easy to resolve: just use whatever magic profile
string is required to tell the XML parser to treat DOCTYPE declarations and
PIs as errors, then we have interoperability across SOAP implementations and
between SOAP and generic XML implementations.
Simon St. Laurent, my usual partner in crime, seemed to by arguing against
the latter "SGML-ish" approach in an earlier message. He's right that this
is out of synch with the XML philosophy of defining one basic syntax that
all applications should understand. But actual practice hasn't been kind to
this philosophical notion; for whatever reasons -- good or bad, I don't want
to re-open the "SML" debate! -- implementers of specialized processors have
NOT been quick to support all the features that XML 1.0 defines. The DOM
defines various optional modules, and SVG has a requirement to define
full/basic/tiny conformance levels in the next version; why not address the
specialized simplicity vs generalized interoperability issue once and for
all by defining multiple conformance levels in XML itself and letting
applications choose the conformance level (or profile) that meets their
needs?
If it turns out that some conformance level/profile that matches what
"developers think the XML specification says" is chosen by most application
developers, then the minimalists will be vindicated; if it turns out that
real-world application developers want the full power of all the stuff you
can define in DTDs, all the "interesting" things you can do with namespaces,
all the wonderful stuff that the PSVI lets the people (ahem, all 5 of them
<grin>) who understand it do ... then that's fine too.