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

Oh, it only seems like 5 years since you asked this question last! oh, wait, it was.

Lets not forget this:

http://www.cookcomputing.com/blog/archives/000551.html

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