[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Constrain the Number of Occurrences of Elements in your XM

  • To: "'XML Developers List'" <xml-dev@l...>
  • Subject: Re: Constrain the Number of Occurrences of Elements in your XML Schema
  • From: tpassin@c...
  • Date: Fri, 05 Aug 2005 19:03:57 +0000

sorting by number of occurrences
I'm going to come in here in agreement with those against the limits, although maybe with different reasons.  Even though the intent may be good - to prevent processing overload, it seems, from what Roger said,  limiting MaxOccurs and recursion often won't accomplish this in real life cases.  Futhermore, the software needs to be able to deal with too-large data sets/documents anyway, no matter what the schema says, because what if someone sent you too large a document anyway?

One of the problems with the limits is that it's really hard to know how big a valid document is going to be.  At least, this is so for many practical documents that have lots of optional components, or that have PCDATA chunks of large but variable size.  If you put in limits that restrict a single element, you could still have a document overload your processor because other parts of the document were too large or complex.

Inversely,  if you restricted every part, then you might not be able to have a valid document when all the optional parts but one were very small, but that one was over the limit.  In this case, the restriction would prevent you from using documents that were otherwise perfectly OK to process.

In other words, the combinatorial aspects of these limitations make it hard or impossible to apply to many practical schemas and still allow pretty large or complex documents.   Naturally, some simple schemas will allow this to be done, but Roger is talking about a general rule.

Second, the limits Roger mentioned are as much imposed by a particular processing implementation as anything else.  You might as well say, don't have a data set too large for memory, because a processor can't sort it efficiently.  Well, yes, but all the serious databases know how to sort efficiently using the disk when the data set is too large for memory.  

What Roger is proposing is just like restricting the size of a data set to the anticipated memory size of the processing computer.  Really, now, when was the last time you looked to see how many data elements your database can sort?  Very few people need to do that, and figure out how to deal with it.

Same for photo processing.  Should we limit TIFF files to 1 GB by spec, because Photoshop might not be able to process one on a 1 GB computer?  No, if I run into trouble because I don't have enough memory for my pictures, I make them smaller, get more memory, or don't try to process them.  Why should it be different for schema definitions?

We all know there can be practical reasons for limiting sizes - for example, not processing a URL of indefinite length.  In that example, too, the length is not constrained by the spec itself (i.e., rfc), but practical software does impose a limit.

I conclude that these kinds of schema limits should not be mandated as a general rule, though they may be good things in particular circumstances.

TomP




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.