[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The <any/> element: bane of security or savior of versioni
hmm, no idea why any came out Any all over the place. cheers, Bryan Rasmussen On 10/19/07, bryan rasmussen <rasmussen.bryan@g...> wrote: > Of course note that some of these examples are overdrawn worst case > scenarios, but I have certainly seen lesser variations of them in some > companies and large organizations that had to deal with Any and could > not. And that were any's that were reasonably walled off from the rest > of the markup (in an element defined as extensible. ) > > Cheers, > Bryan Rasmussen > > On 10/19/07, bryan rasmussen <rasmussen.bryan@g...> wrote: > > Possible problems with Any: > > > > well many problems with things are problems because we cannot count on > > people to either use them correctly, or use the things that depend on > > them correctly. > > > > Let us suppose we have an any allowed in the the following xml fragment > > > > <a> > > <b></b> > > <c></c> > > <d></d> > > {any allowed here} > > </a> > > > > This fragment is in a format of business critical data, not in > > presentational markup. > > This data is handled via a system with some millions of lines of code > > programmed over several years by dozens of people. > > > > The following bugs have been determined to be in the system: > > > > ----------------------------------------------------------------------------------------------- > > If condition X occurs somewhere in the passing of the XML message > > process X is run which recursively goes over the data entering all > > data from elements into a ridiculously bad database structure where > > field names match element names. > > > > When Any occurs in xml documents that are ran through process X the > > system crashes. > > > > Somebody is working on this bug though and they will probably find it soon. > > > > ----------------------------------------------------------------------------------------------- > > > > There are a number of stylesheets for various output media. These > > stylesheets have all been written in the push style to increase > > maintainability and with reference to the definition of elements in > > the namespace. > > > > These stylesheets produce incorrect presentations when ran with > > elements that extend the known namespace - i.e. when any is used. > > Nobody has found out about this yet but somebody has noticed that > > there are validation errors coming out in some instances when the > > instances are ran through the format 2 xsl-fo stylesheets because the > > xsl-fo renderer used is rendereX with validation of the XSL-FO. > > Somebody is trying to debug this but it is somewhat difficult because > > the guy who wrote the stylesheets is no longer there, but nobody at > > the company knows XSL-FO. > > > > Also format 2 legacy html stylesheet produces output that crashes > > Netscape 4 when some infrequent user of that browser shows up. That is > > also set to debug, nobody knows what causes it though. The best guess > > is it is somewhere on the server side not in the transformation, and > > nobody is looking at it because hey, its Netscape 4. > > > > ----------------------------------------------------------------------------------------------- > > > > There are any number of bits of code throughout this big big system > > where someone gets a and has to read the children of a into an array > > and blah blah blah. In some cases depending on how it was done the > > system fails, in other cases the data gets added into the last item in > > the array blah blah blah. In some bits of legacy data from a long time > > ago before they found out they had these problems somebody made > > extension y that had an integer datatype. d was a decimal datatype. In > > some arrays that were really important for calculating some sort of > > tax d and extension y ended up getting concatenated. Nobody has > > actually realized that there are small decimal inconsistencies in the > > data. This will be figured out in the next accounting cycle. > > > > Finally the IT support and consultants and programmers for this large > > organization do not necessarily talk to each other about the bugs they > > find in different non-connected parts. For example that the XSL-FO > > stylesheets have a bug will not necessarily be communicated to the > > programmers trying to figure out where the bug is on the format 2 html > > presentation server. > > > > The upshot is that: given that people do not build large systems > > invariably after best practices one cannot say well just make sure you > > don't do any of those mistakes then. > > > > One must realize that decisions in the extensibility of the format can > > cause those mistakes. > > > > Any in those contexts can lead to higher chances of things being > > [expletive deleted] up. Therefore, while I do not agree that Any is too dangerous > > to ever use, Any is definitely to dangerous to just assume there is no > > problem with it. > > > > Cheers, > > Bryan Rasmussen > > > > > > > > > > > > > > > > > > On 10/19/07, David Carlisle <davidc@n...> wrote: > > > > > > > > > > > > < From a security perspective the <any/> element represents a high risk > > > > and should be avoided if possible. In environments where schema > > > > validation is used in a guarding capacity, a schema that uses the > > > > <any/> element is likely to be marked as high risk or even forbidden > > > > from use. > > > > > > That seems a rather bizare characterisation, and compared to otehr > > > features of XSD (for example lax or skip validation) what is teh problem > > > that you see with <any/> ? > > > > > > David > > > > > > ________________________________________________________________________ > > > The Numerical Algorithms Group Ltd is a company registered in England > > > and Wales with company number 1249803. The registered office is: > > > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. > > > > > > This e-mail has been scanned for all viruses by Star. The service is > > > powered by MessageLabs. > > > ________________________________________________________________________ > > > > > > _______________________________________________________________________ > > > > > > 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@l... > > > subscribe: xml-dev-subscribe@l... > > > 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] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|