[
Lists Home |
Date Index |
Thread Index
]
>This is about deciding what set of features
>can always be relied upon from an XML processor.
Let me amend that: or it is about creating
classes of XML processors by their features
signature and managing these if no single
XML subset can be negotiated and the parties
pleading the case cannot be satisfied by the
status quo.
I think that will be a disaster, a true
dllHellInXML. It could open so many bags o' bugs
that the price for performance will be extra
years until web services are pervasive.
Where do folks want to spend the money? There
ain't no free lunch.
Question: how many of you participating in this
thread have read Tim Bray's XML-SW paper at
textuality.com?
http://www.textuality.com/xml/xmlSW.html
[Tim fellow, make that easier to find from
your index page! I had to go to Google
to find it.]
Perhaps we should, for a strawman's sake, put
that one proposal on the table here on XML-Dev
and debate its merits vis a vis our different
applications. I'm not for it or against it,
but it is the best documented thinking put
forward that I've seen so far on the subject
of an XML subset. If debated, it would surely
out the differences among the supporters of
this effort.
My objection to it was including namespaces
in THE core. If it is not the core, nevermind;
it is a good place to start on a subset.
len
|
