Re: Fwd: [xml-dev] Not using mixed content? Then don't use XML

[Peter Hunsberger <peter.hunsberger@gmail.com>]

On Tue, Apr 9, 2013 at 3:45 AM, Andrew Welch <andrew.j.welch@gmail.com> wrote:

> I've used XML schemata (DTDs and XSDs) for many years and they have served
> me very well.  Their use has helped me avoid many traps in data that I
> generate and in data that I accept from others, and they have amply paid for
> their use repeatedly.

One issue I still haven't found a good solution or answer to is when
you have additional 'business rules' validation performed by the
application:

- application parses the xml and validates it using the xsd

- the application then performs some additional validation of 'business rules'

This has the following problem:

- the xsd alone isn't sufficient for a 3rd party to check the xml will
parse successfully

Well, they can maybe validate the  XML will parse successfully, they can't validate that the data is completely correct,

 

Do you then:

- move all the business rules into the XSD ?

H3ll no!  That would just make things worse. Schema is just another tool to for standardizing some of the metadata, you should not expect to use it for all the metadata.

 

or

- provide 3rd parties with the parsing side of your app, so they can
verify the xml using that ?

H3ll no!  Well, except for the free code review perhaps...

I've built a system that did validation via dynamically generated Schematron.  The rules used to generate the Schematron came from XSLT transformations of XML generated from thousands of rows of relational data.  Those rows of data were the developers and business analysts best attempts at coding up the rules of various medical protocols, documents on security practices, agreements on data exchange between institutions, many government regulations, etc. We also could generate rudimentary XML schema that documented the data types. This was in fact aimed at data exchange partners via web services.

For most of my purposes, XML schema defines the data formats and type to allow the standardized exchange of data.  The exchanged data may still be bad.  Other layers of documentation (possibly coded up as XML of some form) might in turn document why the data is good or bad. However, for the most part you have to back all this up with the documentation on which it was based.  The third party can then attempt to make their best implementation of these layers of documentation. If, at some point, we end up with a technical mismatch between organizations we attempt to first resolve it technically, then via the bureaucrats, but ultimately with lawyers and politicians....

 

Peter Hunsberger