Cart
|
[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
 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 http://xmlbuddy.com/ > 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/ 
|
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
|
|||||||||
