XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The <any/> element: bane of security or savior of versioning?

Interestingly, in UBL the 'any' is inside an optional construct so parties
concerned it might pose some problems for software weaknesses or
security can just impose a subsetting profile which eliminates its use
from their transactions. I too was all for having it in UBL because it
seemed that there was little to distinguish what seemed to be effectively
content which was actually XML from content which was a string - the
string datatype after all could contain the same XML but escaped as
CDATA. UBL seems to have doubled as quite a good proving ground
for all sorts of aspects of XML. I guess I was hoping it would establish
some best practice in that respect.

Regards

-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice


On 19/10/2007, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> 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/
> >
> >
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS