We run into similar issues w.r.t the life cycle of an object when the structure of the object changes over its lifecycle.
One could have a single schema with many things optional and then one having to define constraints tied to the life cycle of the object.
But this approach tends to become unwieldy...
So I like the idea of different schemas:-)
Would be interested in insight on the issues faced in using multiple schemas - haven't had the opportunity to work on such a project...
thanks,
prakash
-----------------------------------------------------------------------------------------------------------
++1
The additional goodie is when the workflow or phases as Rick
calls them are instrumented to enable feedback to the system
that adapts the controls. I might have multiplexed pipes. This
complicates the example but it's real.
One of the high cost items in my market is that Federal standards
for data reporting such as NIBRS and UCR are customized by
each State and often, each agency. Instead of creating a core
standard that remains invariant and then using extensions for
variant, they change the core. That kind of change needs
transparent justification but that is not how it works.
len
-----Original Message-----
From: Michael Kay [mailto:michael.h.kay@ntlworld.com]
> It would be very useful if we could have a simple example
> that shows how
> several schemas might be employed, rather than a single schema. Could
> someone provide an example?
One example I am thinking of is where a document is gradually built up in
the course of a workflow. At each stage in the workflow the validation
constraints are different. You can think of each schema as a filter that
allows the document to proceed to the next stage of processing.
