[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-dev
Subject: [xml-dev] RE: Application of Postel's Principle to XML (was Re: Trust and control )
From: "Costello, Roger L." <costello () mitre ! org>
Date: 2013-02-06 12:28:51
Message-ID: B5FEE00B53CF054AA8439027E8FE17751E6FBD41 () IMCMBX04 ! MITRE ! ORG
[Download RAW message or body]
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
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic