[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]