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

RE: Application of Postel's Principle to XML (was Re: Trust andcontrol )

• From: "Costello, Roger L." <costello@mitre.org>
• To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
• Date: Wed, 6 Feb 2013 12:28:51 +0000

Hi Folks,

Thanks for the excellent feedback. Based on your feedback, I have updated the discussion (see below). I welcome your comments.  /Roger

	Issue: What are ways that senders can be conservative 
	and recipients liberal in the face of a specification that 
	is ambiguous or incomplete, data that is erroneous, or 
	there is new unexpected data?

Postel's Principle says:

    	Be liberal in what you accept, and
    	conservative in what you send.

The intent of Postel's Principle is to maximize interoperability between network service implementations, particularly in the face of:

	- an ambiguous or incomplete specification
	- errors
	- new, unexpected data 

I want to fully understand what it means to apply Postel's Principle to XML.

In particular, I want to compile a list of:

	- Ways to be conservative in what you send.
	- Ways to be liberal in what you accept.

Below I made a start at such a list. Would you add to the list please?

In the list I provide 3 things:

a. Something that requires senders and recipients to make a judgment call:

	A specification that is ambiguous or incomplete, 
	thus requiring senders and recipients to make a 
	judgment call: how should I interpret the specification -- 
	liberally or conservatively? 

	An error in the data, thus requiring recipients to make a 
	judgment call: how should I deal with the erroneous data -- 
	liberally or conservatively?

	New data, thus requiring recipients to make a judgment call: 
	how should I deal with this new data -- liberally or conservatively?

b. A way for senders to be conservative.

c. A way for recipients to be liberal.

----------
Way #1
----------
a. An ambiguous or incomplete specification:

      	The data that is exchanged between
     	 sender and receiver may be well-formed
      	XML.  

	(It's ambiguous/incomplete because
	it says "may" -- is it required to send
	out well-formed XML? Yes? No?)

b. A way for senders to be conservative:

      	 Send out only well-formed XML documents.

c. A way for recipients to be liberal:

      	Accept and process documents, even if
      	they are not well-formed.

----------
Way #2
----------
a. An ambiguous or incomplete specification:

    	The value of the <country> element
      	may be an ISO 2-letter country code.

	(Again notice the use of "may")

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.

----------
Way #3
----------
a. An ambiguous or incomplete specification:

      	The value of the <key> element
      	must be a unique identifier composed 
      	of a string of 1-36 characters.

b. A way for senders to be conservative:

       	Send out only ISO-standard, UUID in canonical form.

c. A way for recipients to be liberal:

      	Accept and process any string of values at least 
     	one character in length up to 36 characters in 
      	length, and that, for the sender, is unique. 

----------
Way #4
----------
a. An ambiguous or incomplete specification:

      	The content of <Book> must be <Title>,
      	<Author>, <Date>, <ISBN>, and <Publisher>.

	(Ambiguity: How many occurrences of these elements?
	Is a specific order required? Can there be other
	elements?)

b. A way for senders to be conservative:

       	Send out <Book> elements consisting of
       	exactly one <Title> element, followed by one 
       	<Author> element, followed by one <Date> 
      	 element, followed by one <ISBN> element, 
       	followed by one <Publisher> element, and 
       	nothing else. 

c. A way for recipients to be liberal:

      	Accept and process <Book> elements consisting
      	of one or more <Title> elements, one or more
      	<Author> elements, one or more <Date> elements,
      	one or more <ISBN> elements, one or more <Publisher>
      	elements, and other elements. And the elements can
      	occur in any order. 

----------
Way #5
----------
a. Example of the recipient receiving erroneous data:

      	The content of <binding> must be either
      	"softcover" or "hardcover" and nothing
      	else.

b. N/A 

c. Recipients receive this erroneous data: 
	<binding>avocado</binding>
    A way for recipients to be liberal:

     	 Ignore the erroneous data and instead
	assume the binding is "softcover". 

What other ways can senders be conservative and recipients liberal in the face of a specification that is ambiguous or incomplete, data that is erroneous, and new/unexpected data?

/Roger

More on Postel's Principle:

 http://queue.acm.org/detail.cfm?id=1999945 

http://tools.ietf.org/html/rfc1122 

http://www.ietf.org/rfc/rfc1123.txt