OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Constrain the Number of Occurrences of Elements inyour XML

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Re: [xml-dev] Constrain the Number of Occurrences of Elements inyour XML Schema
  • From: Greg Hunt <greg@firmansyah.com>
  • Date: Mon, 08 Aug 2005 21:42:22 +1000
  • In-reply-to: <E1E22AU-0000YW-8h@mx.mailix.net>
  • References: <E1E22AU-0000YW-8h@mx.mailix.net>
  • User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Michael,
Lets not lose sight of the question: do we put operational constraints 
on occurrence counts in the schema or do they go somewhere else in which 
case the schema only represents the theory of the data model?  If 
elsewhere, should there be tool support? 

Whether the schema is used for validation of all incoming data is 
another, very different question.  Schemas can be used for interface 
specification and verification as well as for production data 
validation.  I agree that running schema validation on all incoming data 
would be a bad idea, the phrase "prohibitively expensive" comes to mind 
and I'd rather specify and test than validate everything exhaustively 
and expensively.
 
My point in reply to you was also that out of memory errors display 
horrendously complicated behaviour in high volume environments.  You 
picked a very relevant example that is not at all simple.  Bouncing or 
reprioritising transactions at runtime is only the right way to handle 
significant transactional loads when the decision cost is trivial.  The 
cost of making the decision whether to bounce when using complex XML is 
probably not going to be trivial unless there is some cheaply located 
indicator of probable processing cost in the data and by implication, in 
the schema.  That would be worse than applying limits to numbers of 
elements. 
 
I'd rather specify clearly up front what can and will be processed in 
some tool-supported manner rather than partially in a schema and 
partially in documents and emails and partially in comments in the 
schema or in other places where they will be lost, not maintained or 
misinterpreted.  This is clearly not everyone's concern, but I think its 
a significant issue.
 
Greg

Michael Kay wrote:

>>Michael,
>>Why do you think I am talking about out of memory (OOM) errors?  I 
>>haven't mentioned them.  I am more interested in managing 
>>throughput. 
>>    
>>
>
>I haven't followed the thread closely enough to remember who said what, and
>I wasn't directing comments at anyone in particular.
>
>But someone on the thread was definitely talking about using schema
>constraints to prevent requests being made on underlying layers of the
>system that exceeded their capacity. I took "out of memory" errors as a
>simple example of that idea.
>
>I take your point that in transaction processing it may well be necessary to
>analyze the requests being made on the system and bounce some of them (or
>give them suitable scheduling priority) in order to protect system
>throughput. However, I doubt that schema validation is a good way of doing
>that.
>
>Michael Kay
>http://www.saxonica.com/
>
>
>
>  
>




 

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

Copyright 2001 XML.org. This site is hosted by OASIS