Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
