Calendar

January 2007
M T W T F S S
« Dec   Feb »
1234567
891011121314
15161718192021
22232425262728
293031  

January 2, 2007

Two more reasons why validation is still harmful

Filed under: integration — Mark Baker @ 12:45 am

Another way to look at the validation problem is through the eyes of a software architect. We’re often concerned about “encapsulation”, the practice of keeping related business logic and data together. That practice can take the form of “objects” in OO systems, or just through the partitioning of data and processing logic in non-OO systems. In either form, the value there is that maintainability is improved.

Schemas, on the other hand, when used in a typical “gatekeeper” style – where the software doesn’t see the document until after it’s passed validation – break encapsulation by enforcing some business rules separately from the software responsible for them. In practice, it’s rarely the case that software doesn’t also have some of these rules, meaning that they’re duplicated, creating a maintainability issue.

Yet another way of looking at the problem is as a communication problem (or lack thereof in this case). In the scenario described in the previous post, the meaning of the document with the field value of “4″ is still unambiguously clear to both sender and recipient, it’s just that the recipient isn’t expecting that specific value, and so it rejects the whole message as a result.

It’s true that there will be cases where unknown values like this need special attention; for example, if the “4″ represented “nuclear core shutdown procedure #4″ and the software only currently knows numbers 1 to 3. But we know how to handle those cases – by defining sensible fallback behaviour as part of our extensibility rules – and schemas play no part in that solution. More often than not, software which can handle the value “3″ can also handle the value “4″ without any trouble; an age of “200″, a quantity of “100000″, the year “8000″, a SKU following a non-traditional grammar, etc…, and the only reason we don’t accomodate those values is because we don’t currently believe them to be reasonable.

But that’s really no way to write long-lived software, is it? To expose – essentially as part of the contract to the outside world – a set of assumptions made at some soon-to-be-long-past point in time? Is this anything less than an announcement to the world of the inability of the developers of this software to adapt? Isn’t it also an implementation detail, further eroding the separation of interface and implementation?

If the message can be understood, then it should be processed.

• • •

3 Comments »

  1. More on Validation

    Does validation mean that interface and implementation are tightly coupled, makig a service hard to maintain? Mark Baker posted some more questions on validation yesterday. Validation does have merits in some cases, and the bigger challenge is designin…

    Trackback by subbu.org — January 3, 2007 @ 11:51 pm
  2. [...] I just ran into a disaster scenario which Mark Baker recently described as the way things should be: a new message exchange without schema validation. He writes: “If the message can be understood, then it should be processed” and in a comment “I say we just junk the practice of only processing ‘valid’ documents … and let the determination of obvious constraints … be done by the software responsible for processing that value.” I’ll show this is unworkable, undesirable and impossible (in that order). I’ve got an application out there which reads XML sent to my customer. The XML format is terrible, and old – it predates XML Schema. So there is no schema, just an Excel file with “AN…10″ style descriptions and value lists. It is built into my software, and works pretty well – my code does the validation, and the incoming files are always processed fine. [...]

    Pingback by Marc de Graauw - Random Notes » Blog Archive » Validation Considered Essential — February 13, 2007 @ 6:25 am
  3. [...] David Baron of Mozilla has chimed in on a topic near and dear to much of the work we do at Coactus. It looks like it’s part one of a series; I look forward to the rest. [...]

    Pingback by Integrate This»Blog Archive » David Baron on versioning — March 25, 2007 @ 9:33 am

Comments RSSTrackBack URI

Leave a comment

You must be logged in to post a comment.

Powered by: WordPress • Template by: Priss