Of course that is more in agreement than in disagreement with your
points. One of the implications of your breakdown, in fact, is the way
it raises the question of scope. Historically, validation has been
looked on as something that could be done on each instance
independently and without reference to a broader set of instances (or
indeed other 'dynamic' aspects of system state or context). But that
isn't really the way the world works, at least not all the time.
That reminds me of a challenge in a past project where we wanted to validate a
document against different rules at different stages of its life-cycle. (What’s
acceptable as a submission from an author isn’t necessarily acceptable as a
finished publication).
Managing multiple schemas for the same instances is very cumbersome - how do
you keep them in sync?
One thing I’ve played with in Saxon’s XSD implementation is the idea that a
schema should be parameterized. Currently that only extends to variables in
assertions, but I’ve always thought it could and should be generalized, e.g.
_minOccurs=“{if ($status=‘draft’) then 0 else 1}”
Meanwhile, if you need to do this kind of thing, there is always XSLT (either
to transform the instances, or to transform the schemas…)
Michael Kay
Saxonica
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--