[
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
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/
|
