Lists Home |
Date Index |
> > 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.
Great example Michael. I built a system for a telecom/network equipment
reseller that managed the state of the order from conception (when someone
on the web site placed an order), to completion using an ever growing XML
document. For this simple process we had 7 schemas:
1. Order Entry Validation Schema (want to make sure I know what was ordered,
the prices charged, who it is to, and how to bill)
2. Parts/Catalog Validation Schema (want to make sure the parts are right,
don't care about anything else)
3. Receiving Validation Schema (want to make sure what I ordered was
delivered, costs match catalog, disposition, etc.)
4. Dispatch-Ready Validation Schema (do I have the parts, do I have someone
assigned, do they have time, is customer ready, etc.)
5. Installation Complete Validation Schema (did customer sign off, were
there extra parts needed, was extra time needed, etc.)
6. Billing Validation Schema ( is the amount correct, do discounts apply,
has the bill been sent, etc.)
7. Accounts Payable Validation Schema (did the customer pay, on time, the
right amount, etc.)
Could I have done this with a single schema? Only if all the things in steps
2-7 were "optional".
Even then, would I want to? No, because each of the steps represented a
business stakeholder, and it was near impossible to get ALL the stakeholders
in a meeting, much less get them to agree.
Now each business step is de-coupled, and can grow (do systems ever shrink?)
independently. And in the end, we have a single XML document that reflects
the entire purchase cycle (as well as having the pertinent data in 5
different backend systems).
In this case, the XML database (although NOT the database of record) let us
do things we NEVER could have done across the 5 legacy applications (all
built on "different" relational database technologies).
That is why this telecom/network reseller uses multiple schemas and a XML
I am not advocating throwing out your existing databases (systems rarely if
EVER go away), but simply trying to expand the horizons of what can be done
when the stack is XML end to end.