Hi Roger

I'd take UBL as an example (as usual for me). Datatypes: The standard UBL schema set has many elements with normalizedString as their datatype and very few if any of these have restricted lengths. I have, say, a finance system Accounts Payable application receiving invoices in the UBL format but my application can only receive an Invoice Line Item description with a maximum of 150 characters. I know I'll be storing the UBL XML elsewhere as well as in the Accounts Payable finance system but still I want every invoice record to miminise any truncation of this description. I also want to protect it from abusive excessively long descriptions (or, indeed, any content which is excessively long and could be a denial of service or buffer overload attack). I therefore subscribe to a community-led customisation of UBL which restricts those description lengths. The community-led restriction is not exactly what I want (it restricts to 200 characters) but in other cases it is perfect (e.g. for amounts which it restricts to 100 billion GBP in most cases that matter to me) and anyway, it is free to use and well-known so I can easily ask a supplier to send all invoices using UBL but with this restriction customisation.

When I send invoices, I use UBL still and it is a different product I use for the Accounts Receivable which uses UBL but complies with a different customisation. Most of my buyers accept this customisation because it is so generic (an EU-backed one) but it doesn't have those restrictions on the string lengths, just restrictions on which elements are included in an invoice. What do I care, though, because my Debtors system stores Invoice Line Item descriptions with up to 250 characters and I can send the whole string without worry about it being accepted. Howvere my buyers do care about this and sometimes there are errors in their systems so over time I decide to get the invoice entry clerks to all agree to restrict the descriptions they enter into their invoices to just 100 characters to avoid these problems and improve our cash-flow.

----

Stephen D Green

On 21 June 2015 at 13:06, Costello, Roger L. <costello@m...> wrote:

Hi Folks,

 

[Definition] Bedevil: to cause great and continual trouble.

 

In Eric Raymond’s book [1] he writes:

Consider also Postel's Prescription: “Be liberal in what you accept, and conservative in what you send”. Postel was speaking of network service programs, but the underlying idea is more general. Well-designed programs cooperate with other programs by making as much sense as they can from ill-formed inputs; they either fail noisily or pass strictly clean and correct data to the next program in the chain.

However, heed this warning:

	The original HTML documents recommended “be generous in what you accept”, and it has bedeviled us ever since because each browser accepts a different superset of the specifications. It is the specifications that should be generous, not their interpretation.
-- Doug McIlroy

McIlroy urges us to design for generosity rather than compensating for inadequate standards with permissive implementations. Otherwise, as he rightly points out, it's all too easy to end up in tag soup.

--------------------------------------

What does it mean to create a generous specification? Does Postel’s Prescription apply to XML Schema design? Suppose I create an XML Schema for, say, books. What would a generous book XML Schema look like?

 

Postel’s Prescription says that my applications should accept/process XML inputs that are kind of lousy, but my applications should only send out XML documents that are perfect. Can you give an example of a kind of lousy book XML document that my applications should accept/process and a perfect book XML document that my applications should send out?

 

/Roger

 

[1] Fabulous book: The Art of Unix Programming. It’s available (for free) online at http://www.catb.org/esr/writings/taoup/html/

 

[2] This Wikipedia article defines “tag soup”: https://en.wikipedia.org/wiki/Tag_soup