XML feature manifest/profile (was RE:: [xml-dev] Re: determining ID-ness in XML )

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Sean McGrath [mailto:sean.mcgrath@propylon.com]
> Sent: Saturday, November 24, 2001 6:40 AM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Re: determining ID-ness in XML
> 
> 

> This is the problem I was scratching at with XFM
> almost exactly two years ago now:
> http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Dec-1999/0002.html
> 

And that's the problem I was scratching at with: 
"5) Refactor the various specs so that they layer cleanly, and add some sort
of "features" or "profile" string to negotiate the feature set
between the processor and the application."
http://lists.xml.org/archives/xml-dev/200111/msg00794.html

Someone replied that this could threaten the stability of XML.  I disagree,
for two reasons:

1 - The XML in actual use outside the community of XML specialists is so
basic (I'll use SOAP once again to illustrate this) that few real
applications would break in the refactoring.  Sometime you just have to
re-break the bone, set it cleanly, and THEN it will heal properly ... but
you have to do that early to get good results.

2 - Historically, favoring "stability" rather addressing fundamental
problems just makes the problem all the bloodier.  The ethnic vs. political
borders in (the former) Yugoslavia, post-colonial Africa, Turkey/Iraq,
Pakistan/Afghanistan quickly come to mind.  Closer to home, think of all the
(soon-to-be unemployed) IT executives who tried to keep out PCs, the
internet, PDAs, wireless internet devices, etc. in the name of the
"stability" of their back offices.   

It seems straightforward to me: either the 256 or 2048 or however many
permutations of XML features there are get handled in an ad-hoc,
application-specific way, or we re-break a few fragile bones, put in some
sort of "feature manifest," and let applications negotiate the feature set
with processors in a standardized way.