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

Re: Constrain the Number of Occurrences of Elements inyour XML

too big edi message
I'd argue that there are two kinds of constraint here.  One is the 
theoretical data model, and I'm inclined to agree that too much detail 
there is a bad thing.  The second constraint is a statement of what the 
actual system is willing to, or can do.  We need both kinds of 
constraint but are forced to express them in using the same attributes 
and that is where the problem arises, a conflict between system 
specification and data model.

The second type of constraint, the practical capacity constraint, is 
important if we are to distribute and/or enforce statements about 
performance and capacity.  For example I may regard maxOccurs=3 
differently to maxOccurs="unbounded".  Specifying unbounded may be true 
for the data model when 3 is the real operational number.  The example 
of the number of <p> elements that Mozilla can handle illustrates this.  
If, in some hypothetical system, I have some hard browser UI performance 
requirement, that requirement will be on specified hardware with 
specified software and I will feel free to specify the number of <p>s 
based on that, regardless of the data model for the English language 
saying that maxOccurs is unbounded for paragraphs.  The idea that we 
have to handle anything that is thrown at us means either that we have 
no performance constraints, no software cost constraints, or that we 
have to have any amount of capacity sitting around waiting for 
arbitrarily large documents. 

There was an example of image processing given earlier, talking about 
TIFFs and file sizes, but in any production system there should be 
something that says that the file format is TIFF AND also something that 
says that the maximum size is 1GB (or whatever it is).  Businesses 
cannot undertake to process things that consume arbitrary amounts of 
system resource.

The problem of public standards is an interesting one and experience 
with EDI is worth looking at.  Typically the basic EDI message type is 
constrained further, outside of the EDI specification, by a local, 
partner specific profile, before it can be used for interchange.  A few 
months ago I was looking at the EDI profile for interchange with a very 
large retail chain.  This profile specified a subset of the formal 
standard: they specified exactly how many occurrences of what were 
acceptable and what literal values were acceptable where.  This wasn't 
theoretical data model stuff, this was "do it this way and we will do 
business with you".  Isn't this what we need to be able to support in  
XML?  If we don't put these limits in the schema, they just have to go 
somewhere else, somewhere less visible, less maintainable, and with less 
tool support. How SHOULD we do this if we aren't using the schema for 
validation of these constraints?

Joe English wrote:

>Roger L. Costello wrote:
>>Below I have jotted down a few thoughts regarding XML Schemas which permit
>>an unbounded number of occurrences.  Namely, I recommend against using
>>maxOccurs="unbounded" in an XML Schema.  I am interested in hearing your
>>thoughts on this.
>My thoughts lead to the exact opposite conclusion:
>you should never use anything *except* maxOccurs="unbounded"
>(or maxOccurs="1") in a schema.
>With very few exceptions, any attempt to devise a suitable
>upper bound for any 'maxOccurs' value is bound to involve
>wild-ass-guessery.  How many paragraphs should one allow
>in an HTML document?  You can take this from a business logic
>standpoint ("what's the longest web page anyone is ever
>going to want to produce"), or a processing standpoint
>(how many <p> elements can Mozilla cope with?  What about
>MSIE?  Does your answer change depending on how old the
>user's computer is?), but you'll never be able to come up
>with a satisfactory number.  Whatever number you choose
>will either be too large as a meaningful resource constraint,
>or it will be too small for some existing or future document.
>What you advocate is reminiscent of the QUANTITY and CAPACITY
>sections of the SGML declaration.  These were a perpetual annnoyance
>(the SGML declaration was the first thing that got dumped
>when XML was being designed), and as far as I know they
>never did anybody any good (i.e., they were never an accurate
>indication of how large a document any particular application
>could actually handle).
>>1.	Don't use maxOccurs="unbounded"
>>2.	Don't use recursive constructions
>>3.	Set maxOccurs to a number no larger than the amount of resources you
>>have available
>I'd argue the exact opposite, mostly because (3) is in
>practice impossible to answer, and rarely worth even trying
>to answer in the first place.
>There are only three sensible cardinalities: zero, one, and many.
>There are only four sensible cardinality constraints: mandatory,
>optional, mandatory+repeatable and mandatory+optional.
>(Corrolary: "?", "+", and "*" operators as found in DTDs and Relax NG
>are far more appropriate than WXS' separate minOccurs= and maxOccurs=
>--Joe English
>  jenglish@f...
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>


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.
First Name
Last Name
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.