[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Application of Postel's Law to XML (as Re: Trust and control )
- From: "Costello, Roger L." <costello@mitre.org>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Mon, 4 Feb 2013 16:57:33 +0000
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.
----------
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.
----------
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.
What other ways can specifications be ambiguous or incomplete, senders conservative, and recipients liberal?
/Roger
[1] http://queue.acm.org/detail.cfm?id=1999945
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]