Comments on: Validation Considered Essential

By: Ben Bryant

Ben Bryant — Tue, 03 Apr 2007 20:41:29 +0000

My point is that the title “Validation Considered Essential” does not seem to relate to what you ended up writing about. Using XML validation is your choice, but that seems to be beside the point.

And what about this story involves you telling them what data is allowed in? It seems like you are entering data on their site to get sample data sets to practice processing. It certainly doesn’t sound like you are handing them a schema that they have to conform to, on the contrary, you are being subjected to whatever format they produce.

I took your message to be that if they had given you an XSD your life would have been easier. I can agree with that and I would say use it as a guide to implementing your processing, but don’t actually validate their documents against it, that would have no purpose. If the XSD gets out of sync with theirs it can serve as an early warning system, but you will still have to simply disable the validation and make do with what they are giving you.

By: marc

marc — Tue, 03 Apr 2007 20:13:59 +0000

Ben: “your real problem is getting the other party to *tell you* what the format is”

This was my day job for years (sometimes still is), and yes, that can be a huge problem.

However, I described a situation where *I* have to tell the other party what data is allowed in, and then to validate or not to validate is a choice for me - validate, I’d say.

By: Ben Bryant

Ben Bryant — Tue, 03 Apr 2007 19:48:03 +0000

You can even use a schema initially if you want, if that is really your lingua franca, but your real problem is getting the other party to *tell you* what the format is! This problem you are describing has nothing to with validation vs no validation.

By: marc

marc — Wed, 14 Feb 2007 08:54:54 +0000

Actually I’m quite sympathetic to the idea of using some other form of datatyping for exchanges. I once got terribly fed up with handcrafting schema’s for data which - usually - come from a relational db and end up in one. So I got the idea it should be possible to define any rdb-to-rdb exchange with SQL DDL (CREATE TABLE etc.) and a solid set of deserialization rules from XML into relational tables. Parties then simply exchange the DDL, create the exchange db and send XML. Further processing into the target db can be done with the favorite local tools. Basically this is delegating the datatyping to SQL DDL. The project got stuck in the details, which can be muddy, but maybe I’ll work out the details sometime and see if I can get it published.

But now there is no very commonly accepted way to specify datamodels and -types for XML other than schema’s.

By: Mark Baker

Mark Baker — Tue, 13 Feb 2007 16:48:20 +0000

Thanks for the response. To address each of your 3 examples …

Unworkable - you need a data model to address that problem, not a schema. While a schema can help in specifying one, it is neither necessary nor sufficient.

Undesirable - I don’t understand. Why is it undesirable to have you software do a case-insensitive check? I hope you’re doing this anyway, even if you’re also using a schema, because software should generally validate inputs (hence my point about encapsulation).

Impossible - I agree that explicit data typing is often a good idea in examples like that, but again, a schema is neither necessary nor sufficient to do that. e.g. rdf:datatype.