Re: [xml-dev] Application of Postel's Law to XML (as Re: Trust andcontro

[Frank Manola <fmanola@acm.org>]

Roger--

I think you need to work on your examples a bit.  To my way of thinking, none of your "ways to be conservative" example are really being conservative;  instead, they are expanding on the original specifications.  IMHO, being conservative, in this context, means being careful to conform to the original specification, no more and no less, not adding additional constraints (not necessarily known to the recipients) to the original specification.  Further comments below:

On Feb 4, 2013, at 11:57 AM, Costello, Roger L. wrote:

> Hi Folks,
> 
> Postel's Law says:
> 
>    Be conservative in what you do, 
>    be liberal in what you accept from 
>    others.
> 
> The intent of Postel's Law was to maximize interoperability between network service implementations, particularly in the face of ambiguous or incomplete specifications [1].
> 
> I want to fully understand what it means to apply Postel's Law to XML.
> 
> In particular, I want to compile a list of:
> 
> - Ways to be conservative in what you do.
> - Ways to be liberal in what you accept from others.
> 
> Below I have made a start at such a list. Would you add to the list please?
> 
> In the following list I provide 3 things:
> 
> a. A specification that is ambiguous or incomplete, thus requiring senders and receivers to make a judgment call: how should I interpret the specification -- liberally or conservatively?
> 
> b. A way for senders to be conservative in their interpretation of the specification.
> 
> c. A way for recipients to be liberal in their interpretation of the specification.
> 
> ----------
> Way #1
> ----------
> a. An ambiguous or incomplete specification:
> 
>      The data that is exchanged between
>      sender and receiver must be formatted
>      using markup.
> 
> b. A way for senders to be conservative:
> 
>       Send out only well-formed markup documents.
> 
> c. A way for recipients to be liberal:
> 
>      Accept and process markup documents, even if
>      they are not well-formed.

In #1, you don't explain in what way (a) is ambiguous or incomplete.  A specification isn't necessarily ambiguous or incomplete just because you could add additional constraints to it.  Maybe (a) is exactly what is wanted.  Moreover, you don't say "well-formed" with respect to what specification (in (a) you could have said XML, in which case "well-formed" would be defined;  but you didn't).  Here, (b) is an additional constraint added to (a).  And I would argue that (c) is not "being liberal", it is doing exactly what the original specification (as opposed to your newly-enhanced one) requires.

> 
> ----------
> Way #2
> ----------
> a. An ambiguous or incomplete specification:
> 
>      The data that is exchanged between
>      sender and receiver must be well-formed
>      XML.
> 
> b. A way for senders to be conservative:
> 
>       Send out only well-formed, schema-valid XML documents.
> 
> c. A way for recipients to be liberal:
> 
>      Accept and process well-formed XML documents, 
>      even if they are not schema-valid.
> 

Requiring well-formed XML seems unambiguous to me.  Maybe the specifiers didn't want to require schema-validity.  Again, you are adding a new constraint to the specification, not being more conservative in applying the original one.
  
> ----------
> Way #3
> ----------
> a. An ambiguous or incomplete specification:
> 
>      The value of the <country> element
>      must be the name of a country.
> 
> b. A way for senders to be conservative:
> 
>       Send out only ISO-standard, 2-letter country 
>       codes, e.g., US, CA, GB, DE.
> 
> c. A way for recipients to be liberal:
> 
>      Accept and process any string, e.g., US, 
>      United States, U.S.A.
> 

Similar comments to those above apply.  It is debatable whether "US" is the name of a country anyway (if you mean "The United States of America").  

--Frank