[
Lists Home |
Date Index |
Thread Index
]
> There are some controversial design choicesin the above, but the
> argument for schema validation because it pushes some things down a
> layer does have some merit.
>
> But I don't buy it. If I'm going to be accepting transactions encoded
> in XML my *business* level validation is going to be doing a lot of
> looking up part numbers in catalogues and buyer-IDs in other databases
> and pricing rules and so on and so on. If I'm already doing this in a
> high-volume transaction processing application I think it's going to be
> hard to justify a full-dress schema validation step when the
> business-validation code already knows the data types and can do the
> data conversion right down there inline, and fail deterministically if
> something isn't as expected. -Tim
I am looking at it from the developer's side, doing
a similar thing right now. From my point of view, it would
have been nice to build a Schema/DTD object model from the
Schema/DTD, most likely at design time, which can/will
work like a validator, but at the same time allows me to
plug in my business application logic in the right places.
That way, validation and business logic is carried out
together, and the Schema/DTD has become part of the application,
instantiated in my programming language of choice.
I didn't have time to do it to its full extent in my application,
I just built a very rudimentary form of it.
So, what I am trying to say is: as a separate and unrelated step I don't
see much value in Schema/DTD validation (from the developers perspective),
but being able to pull a validation engine with all its hooks into my application
would have been nice.
Karl
|
