Me either.

OTOH, it won't stop SOAP or any of the other XML subset systems from being
promoted, promulgated and supported by some subset of web system(s) users.
The question is, where in the framework does the user of such a subset check
that this is all they are receiving or sending?  The application, yes?  

It is a contract issue as I stated earlier.   We've dealt with that for all
procurements.  It is problematic where contracting parties don't have the
right expertise in the contracting pipeline and therefore procure or fail to
procure the right components.  As RFPs market begin to exceed 300 pages with
about 60% to 75% per cent of that being technical requirements down to the
field level, it becomes crucial that those who issuing and those responding
are acquainted with the technologies, features and specifying documents in
excruciating detail.  Not surprisingly, many organizations don't have that
level of expertise and some won't pay the right amount of attention to these
processes when they do.

It is a caveat emptor selling environment, but if the buyer is smarter than
the seller, the concept of liquidated damages becomes the big topic at the
vendor's headquarters.

Standards are there to help one avoid that.  Subsets dilute their ability to
do that.  So I like the advice but for purely economic reasons.

len


From: Richard Salz [mailto:rsalz@u...] 

> "tell your customer to install a real XML parser".

I don't really disagree, BTW.

        /r$