Re: [xml-dev] The <any/> element: bane of security or savior of versioni

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

Well clearly this should be done. I think though that I went overboard
in the way I described it. Roger asserted that any was bad and should
be dropped. I asserted that it should be used but dependent on
context, for example in a more controlled manner in applications that
are expected to exchange 'important' business data. This control
should be asserted at the specification level with a well specified
processing model for the any in the application, for which I pointed
to UBL. This was basically my only meaningful contribution to UBL,
IMHO, to try to get it to have an extensibility mechanism secured in a
manner appropriate to the level of importance of the data, although I
was certainly not the only one that had a hand in that part.

I also came to consider, as I was on the way to training tonight, that
my viewpoint of the matter is probably colored by what would be the
obligations of governmental standardization which I believe are
slightly different from the obligations of international
standardization and just plain technical standards.

Cheers,
Bryan Rasmussen

On 10/19/07, Michael Kay <mike@saxonica.com> wrote:
> > > When Any occurs in xml documents that are ran through process X the
> > > system crashes.
>
> Well, clearly you should either fix the bug in the application or put a
> fence around it to protect it from data it can't handle. But the problem is
> just as likely to be that it fails on characters above 65535 as that it
> fails on unexpected elements. Banning xs:any because some applications have
> bugs is like banning high Unicode characters because some applications have
> bugs. It's not xs:any that's the security weakness, it's the buggy
> application.
>
> Michael Kay
> http://www.saxonica.com/
>
>