<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Validate for Machines, not Humans</title>
	<link>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/</link>
	<description>Some thoughts on meaning, the web and everything</description>
	<pubDate>Sat, 31 Jul 2010 19:03:53 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: Marc de Graauw - Random Notes &#187; Blog Archive &#187; Validation Considered Essential</title>
		<link>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-280</link>
		<author>Marc de Graauw - Random Notes &#187; Blog Archive &#187; Validation Considered Essential</author>
		<pubDate>Tue, 13 Feb 2007 10:25:33 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-280</guid>
		<description>[...] 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: &#8220;If the message can be understood, then it should be processed&#8221; and in a comment &#8220;I say we just junk the practice of only processing &#8216;valid&#8217; documents &#8230; and let the determination of obvious constraints &#8230; be done by the software responsible for processing that value.&#8221; I&#8217;ll show this is unworkable, undesirable and impossible (in that order). I&#8217;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 &#8220;AN&#8230;10&#8243; 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. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 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: &#8220;If the message can be understood, then it should be processed&#8221; and in a comment &#8220;I say we just junk the practice of only processing &#8216;valid&#8217; documents &#8230; and let the determination of obvious constraints &#8230; be done by the software responsible for processing that value.&#8221; I&#8217;ll show this is unworkable, undesirable and impossible (in that order). I&#8217;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 &#8220;AN&#8230;10&#8243; 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. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Baker</title>
		<link>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-80</link>
		<author>Mark Baker</author>
		<pubDate>Wed, 03 Jan 2007 17:57:22 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-80</guid>
		<description>Agreed, a positive integer would be a far more reasonable constraint because it's less apt to change over time.  But schema users haven't, IMO, gotten this point, and most schemas I've seen have the most brittle of assumptions built in (heck, that example is from the XSD primer where you'd expect to see best practice practiced!!).  Besides, the schema specs largely limit extensibility by default, meaning that it takes a guru to develop a decent schema.  So I say we just junk the practice of only processing "valid" documents (as my latest post explains in more detail), and let the determination of obvious constraints (such as positiveInteger) be done by the software responsible for processing that value.</description>
		<content:encoded><![CDATA[<p>Agreed, a positive integer would be a far more reasonable constraint because it&#8217;s less apt to change over time.  But schema users haven&#8217;t, IMO, gotten this point, and most schemas I&#8217;ve seen have the most brittle of assumptions built in (heck, that example is from the XSD primer where you&#8217;d expect to see best practice practiced!!).  Besides, the schema specs largely limit extensibility by default, meaning that it takes a guru to develop a decent schema.  So I say we just junk the practice of only processing &#8220;valid&#8221; documents (as my latest post explains in more detail), and let the determination of obvious constraints (such as positiveInteger) be done by the software responsible for processing that value.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: marc</title>
		<link>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-65</link>
		<author>marc</author>
		<pubDate>Fri, 22 Dec 2006 15:25:10 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-65</guid>
		<description>That's a perfect example of a constraint that should not be there - and I agree with you one should not include validations which make no business sense, and there are way too many of those.

However, in this example, if we accept only ordered quantities &gt; 0, like we probably should, it makes a lot of sense to define quantity as xsd:positiveInteger, not xsd:integer, and it makes sense to lay this rule down in a schema and reject incoming messages which violate it. If my customer orders minus one pencils, his software must be broken. The schema describes what I'm willing to accept, and I should be generous, but not that generous. What my apps down the line can or cannot accept (not -1 in this case) is no information for my customers, therefore I need a schema for this - or prose, but just prose seems a step back.</description>
		<content:encoded><![CDATA[<p>That&#8217;s a perfect example of a constraint that should not be there - and I agree with you one should not include validations which make no business sense, and there are way too many of those.</p>
<p>However, in this example, if we accept only ordered quantities > 0, like we probably should, it makes a lot of sense to define quantity as xsd:positiveInteger, not xsd:integer, and it makes sense to lay this rule down in a schema and reject incoming messages which violate it. If my customer orders minus one pencils, his software must be broken. The schema describes what I&#8217;m willing to accept, and I should be generous, but not that generous. What my apps down the line can or cannot accept (not -1 in this case) is no information for my customers, therefore I need a schema for this - or prose, but just prose seems a step back.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Baker</title>
		<link>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-64</link>
		<author>Mark Baker</author>
		<pubDate>Fri, 22 Dec 2006 13:58:34 +0000</pubDate>
		<guid>http://www.marcdegraauw.com/2006/12/22/validate-for-machines-not-humans/#comment-64</guid>
		<description>Check out "quantity" in this example schema;

http://www.w3.org/TR/xmlschema-0/#po.xsd

Are you telling me that software that's written to support the value "100" can't support "101"?</description>
		<content:encoded><![CDATA[<p>Check out &#8220;quantity&#8221; in this example schema;</p>
<p><a href="http://www.w3.org/TR/xmlschema-0/#po.xsd" rel="nofollow">http://www.w3.org/TR/xmlschema-0/#po.xsd</a></p>
<p>Are you telling me that software that&#8217;s written to support the value &#8220;100&#8243; can&#8217;t support &#8220;101&#8243;?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
