[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fallacies of Validation ... RE: Are people reall


parts catalog xml schema
> >
> > 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
database.

 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.

Owen



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.