[
Lists Home |
Date Index |
Thread Index
]
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: Michael Brennan <Michael_Brennan@Allegis.com>,"'Mike.Champion@SoftwareAG-USA.com'" <Mike.Champion@SoftwareAG-USA.com>
- Date: Mon, 13 Nov 2000 08:58:55 -0600
Title: RE: Dangers of Subsetting? (was RE: Pull-based XML parsers?)
Do you
have any problems with pulling an object out of an
object
library and examining its methods and properties
to
determine how of if you will use it in code? A standard
profile should work something like that. The problem is
when
someone develops a specification from fuzzy requirements
then
calls the result of that work "a standard" withut regard
to
creating tests to prove an implementation meets the
requirements. If I create an object in a library and its
capabilities are "fuzzy", just how reliable is
it?
Len
http://www.mp3.com/LenBullard
Ekam
sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
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?
| 