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 ]

Greg Hunt wrote:
> 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?

This is getting a bit repetitive. The majority of posters to this thread 
disagree with Roger's assertion that schemas should be used to specify 
operational constraints. That would seem to put them elsewhere.

It's also apparent that not everyone agrees there is a need for 
operational constraints. For those who do want them, it's not at all 
obvious they should be specified at the data model level. Excessive 
recursion exceeds the limits of a given environment regardless of 
element type. Likewise for out-of-memory conditions caused by too many 
elements or implementation bounds exceeded by too-large text values.

Asking for tool support at this stage is akin to asking for zoo space 
for unicorns. There is nothing to support.

Bob Foster

> 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