[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

=?UTF-8?Q?Re=3A_=5Bxml=2Ddev=5D_Should_XML_applications_follow_Postel?==

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Fri, 13 Apr 2018 00:34:25 +0000

=?UTF-8?Q?Re=3A_=5Bxml=2Ddev=5D_Should_XML_applications_follow_Postel?==
Oh, it only seems like 5 years since you asked this question last! oh, wait, it was.

Lets not forget this: 

This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software.

Jon's principle could perhaps be more accurately stated as "in general, only a subset of a protocol is actually used in real life. So, you should be conservative and only generate that subset. However, you should also be liberal and accept everything that the protocol permits, even if it appears that nobody will ever use it."

So you make sure your XML-in/XML-out filter transfers comments and PIs, even if you dont use them yourself...

For xsd:boolean which allows 0/1/true/false, Postel's Robustness Principle says that if most people use true/false then you generate true/false but you accept 0/1/true/false.

Perhaps you should be careful to say that what you are calling Postel's Law is the opposite of what he was actually saying?

(Also, in the back of my mind is an idea that because this about robustness, the main thrust was on preventing network processes from crashing or hanging. For example, for HTTP this would be "if you get a verb you dont implement, dont crash or use sone other verb but respond properly with a 405")

So this only relates to optional parts of a spec. In XML there are only three optional things: version, standalone, character encoding. Postel's Principle would be to generate XML 1.0 with no Doctype declaration (and labelled standalone=yes) and UTF-8, but to use a conforming parser that can cope if the input does have an external DTD (in the absense of security issues rtc.) or 1.1 or expectable encodings. 

Regards
Rick

On Thu, 12 Apr. 2018, 23:42 Costello, Roger L., <costello@mitre.org> wrote:

Hi Folks,

Postel’s Law says this: Be generous on input, strict on output. This means that the code should be tolerant of variations in its input but should be strictly correct when outputting data. As an example, when you accept a boolean as a string, ignore the case and allow it to be expressed as “1, 0, T, F, Y, N, TRUE, FALSE, YES, NO, etc.”. But when outputting a boolean as a string, stick to one single convention and one single case religiously. [1]

So …………

Suppose an application validates XML inputs against an XML Schema. One part of the schema says that the <isFlyOver> element must contain a Boolean value. Here’s how that element is declared:

<xs:element name="isFlyOver">
   
<xs:simpleType>
       
<xs:restriction base="xs:string">
           
<xs:enumeration value="true" />
           
<xs:enumeration value="false" />
       
</xs:restriction>
   
</xs:simpleType>
</xs:element>

 

That element declaration says XML documents must contain either this:

<isFlyOver>true</isFlyOver>

or this:

<isFlyOver>false</isFlyOver>

Suppose an application receives an XML document containing this:

<isFlyOver>TRUE</isFlyOver>

or this:

<isFlyOver>1</isFlyOver>

Should the application follow Postel’s Law and accept those XML inputs? And then rebuild the XML so that the output strictly adheres to the schema:

<isFlyOver>true</isFlyOver>

That is, the application validates inputs against this slightly looser schema:

<xs:element name="isFlyOver">
   
<xs:simpleType>
       
<xs:restriction base="xs:string">
           
<xs:enumeration value="true" />
           
<xs:enumeration value="TRUE" />
           
<xs:enumeration value="T" />
           
<xs:enumeration value="YES" />
           
<xs:enumeration value="1" />
           
<xs:enumeration value="false" />
           
<xs:enumeration value="FALSE" />
           
<xs:enumeration value="F" />
           
<xs:enumeration value="NO" />
           
<xs:enumeration value="0" />
       
</xs:restriction>
   
</xs:simpleType>
</xs:element>

 

If the input validates against that schema, then the application rebuilds the XML to conform to the strict schema.

Thus, if the input arrives as this:

<isFlyOver>TRUE</isFlyOver>

then the application accepts it and outputs:

<isFlyOver>true</isFlyOver>

What do you think? Good idea for applications to follow Postel’s Law? Bad idea? Good in some applications and bad in others? Thoughts?

/Roger

[1] http://tedwise.com/2009/05/27/generous-on-input-strict-on-output

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.