Hello grp:
Given the following scenario, I'm hoping someone can suggest the best method
for accomplishing xml validation.
We have a system that accepts requests in the form of xml messages. We
publish schemas detailing the contents and constraints of these requests.
The service is available to both outside and internal consumers. We use
xsd.exe to generate a 'type-safe' document from these schemas. The document
structure is too broad to go into every detail but I will try and sum up as
best I can some of the constraints. It is a composite-like pattern where
several elements act as containers for subtypes. Here is a basic structure
that the system supports:
request --root
applicantInfo --made up of address information, names, phone #'s etc...
package -- packages contain 1 or more products
product -- a product that makes up a package - abstract
element
It is no trouble to validate the schema of the doc to the 'product' node but
then it gets a little more difficult. Certain products require 'upstream'
applicant information to be present when the request is submitted for those
products but it is not ALWAYS required.
EX: System receives a request for a 'credit report' product. Credit
reports require a full address (at least 1).
By the time I am validating the credit report product nodes, I've already
validated the applicant information. At the time the applicant information
was validated, address information wasn't madatory but the discovery of a
credit report product makes it mandatory. I cannot require an address in all
cases since most other products don't require one and it's not reasonable to
expect one.
In the past (this is several generations of the system deep), we've always
used the schema for a baseline validation of the minimal set of information
common to all requests and then used XPath to validate the upstream
information once its dependencies are discovered. Whereas it's always
worked, I never felt it was a good method for doing so and was hoping there
is a more elegant method for addressing this. I should state that this is a
system rewrite and under the new system, the complications get even worse due
to customers have the ability to define their own dependencies in addition to
our baseline information. Individual customers making these requests might
have a different set of minimal information than what our default schemas
require. Also, their individual users might also have different requirements
than what the customer's baseline information requires.
EX: Customer XYZ requires all the default information we require to submit
a request, plus they require a phone number to be filled out in all cases
regardless of product. XYZ's user Tammy has to inherit all of her company's
required fields plus she is required to gather a fullname when a certain
product is selected but not in other products.
The example described above makes the situation even worse because now the
baseline (minimal) information required to make a product request changes per
customer and potentially per user and still depends on the products chosen to
make certain information required at runtime.
I have a pretty solid membership model that can address the customer/user
issue and gather their required attributes in a request but I am missing is
the way to apply it to the validation routine. You can see why I really don't
want use XPath to validate the upstream information since it could change
dramatically per customer/user and it becomes very hard to store this info
reliably. I will if I have to but I'm hoping someone can suggest an
alternative.
Thanks all,
