[
Lists Home |
Date Index |
Thread Index
]
- From: Michael Brennan <Michael_Brennan@Allegis.com>
- To: "'Mike.Champion@SoftwareAG-USA.com'" <Mike.Champion@SoftwareAG-USA.com>
- Date: Fri, 10 Nov 2000 17:18:34 -0800
Title: RE: Dangers of Subsetting? (was RE: Pull-based XML parsers?)
There
are a lot of people with many different opinions about what features are useful
in XML and what are not. These opinions are all valid, but anyone who
values interoperability must be willing to make compromises in this regard. If
"profiling" means that every time I obtain an XML parser, I need to peruse
through a shopping list of features to see which ones this parser supports, than
the value of the standard has been greatly undermined. What is the motivation of
wanting such profiling? Is it to make it easier to implement parsers? Think
about how many times developers obtain and use a parser versus how many times
developers implement a parser. Does it really make sense to greatly complicate
matters for those trying to obtain and use a parser in order to simplify matters
for that much smaller number of developers who are going to implement
parsers?
I have
very high regard for Common XML and the work that went into defining it. I would
be happy to see an official recommendation specifying Common XML. I think there
is value in having layered standards and protocols where there is a clearly
identifiable, simple core, and additional layers that build on top to provide
richer functionality without forcing those who don't need that functionality to
deal with the added complexity. For that to work and be of value, though, the
number of layers needs to be kept small and manageable. In addition, I think
this works best if the "upper" layers are complete supersets of the lower
layers, rather than being arbitrary subsets with (possibly) additional
functionality. If instead of having layers, you have a shoppping list of
features and implementors can provide profiles specifying the particular
features they are supporting, then you have made things far more complex for
those trying to leverage the technologies and you have undermined the value of
the standard.
The only
situation where "profiling" of this sort makes sense, in my opinion, is in cases
where a one-size-fits-all general solution cannot adequately address
requirements. In such cases, leveraging profiling for architectural flexibility
can be a good solution. If, however, the motivation is to simplify
matters in the small number of cases where someone is implementing a general
tool at the expense of greatly complicating matters in the much larger number of
cases where someone is going to use a general tool, then I think the priorities
are all wrong.
I
admit I have no understanding of ISO 8859 Annex K, and I'm no expert on
standards. But I do know quite a bit about the pains I have gone through as a
developer. In my own work, I have always been willing to put extra effort into a
tool I build if it is going to simplify things for me in the many instances in
which I use the tool. In my opinion, standards should be written with the same
philosophy in mind.
-----Original Message-----
From: Rick
JELLIFFE [SMTP:ricko@geotempo.com]
Sent: Friday, November
10, 2000 3:40 PM
To: xml-dev@lists.xml.org
Subject: Re: Dangers of Subsetting? (was RE: Pull-based XML
parsers?)
No-one has said Common XML (as a data format)
is dangerous.
I said that developers
should boycott parsers that call themselves
XML but only implement a subset except for specific-purpose
systems:
so you it is fine to make a
subset parser (e.g. for SOAP) and
say
"this is a parser for a subset of XML" but it is not fine to
say "this is an XML parser".
This makes perfect sense to me. I'm sorry if I misunderstood
the original "boycott" post (I guess I thought it was clear that kXML just
claimed to implement "Common XML", but let's not reopen old
wounds).
And thanks for the
explanation of ISO 8859 Annex K -- I guess if anyone gets really serious
about promoting "Common XML Core" or "MinML", it would make sense to
define it in the official Annex K manner first.
One issue that generated a lot of
traffic on this list a year ago was whether XML needed a similar mechanism
with which one could define a "profile" (as Len Bullard used the term it in
http://lists.xml.org/archives/xml-dev/200011/msg00176.html)
that constrained the types of markup to be used in a class of XML
applications (e.g., "no PIs, notations, parsed entities or CDATA sections,
please" - perhaps if the format needs to be "Desperate Perl Hacker
Friendly"). Isn't this more or less what Annex K allows? Would the people
who so vigorously oppose defining "subsets of XML" in the name of
interoperability be averse to adding a mechanism like this in a future
version of XML?
|
