[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
RE: Heed this warning about Postel's Prescription
- From: "Len Bullard" <cbullard@hiwaay.net>
- To: <stephengreenubl@gmail.com>, "'Costello, Roger L.'" <costello@m...>
- Date: Fri, 26 Jun 2015 17:42:18 -0600
In practice, it seems to be tightening and
relaxing schemas to get the most combined local effect on element production, eg.
Using the schema to validate local proper subsets that conform to local rules
of style where local is an XML production system. Schema at
delivery and schema in production should not always be the same schema.
Seems like a d’oh but hardwiring those in the contracted process cuts the
nuts off the local XMLers. They need to be able to tune the bitch
and some shops don’t because they don’t know they can.
The first document one wants to see when accepting an XML project (say
datasets) is the batch validation report: not the content but the precise
XML state on delivery. That schedules what follows as classes of
known and unknown fixes to be applied to the lot. Do that first and fast
then the redline resolutions go faster. Since change of content is the
hardest to track during a transition (xml shop to xml shop because the info
owners are using the xml record of authority and it drifts out of sync with the
source datasets (system of note is evolving at a different rate).
len
-----Original Message-----
From: Stephen D Green
[mailto:stephengreenubl@gmail.com]
Sent: Monday, June 22, 2015 3:16
AM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: Re: Heed this
warning about Postel's Prescription
This, by the way, was a fictional scenario but I would
think it a typical scenario.
Anyway, in this scenario I would be breaking the
golden rule "Do unto others as you would have them do unto you" and
of course breaking Postel's Law. (And I would say the example shows Postel's
Law to be a form of that golden rule.) To keep both rules I would need to
have my invoice-sending app conform to the more restrictive customisation of
UBL which restricted string lengths and use the less restrictive one for
specifying what suppliers should use to send me invoices. Then I would need to
improve how my Accounts Payable app stores those descriptions and maximise the
sue of the raw XML storage of the full strings sent me.
On 22 June 2015 at 09:52, Stephen D Green <stephengreenubl@gmail.com>
wrote:
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.
On 21 June 2015 at 13:06, Costello, Roger L. <costello@mitre.org>
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
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
RSS 2.0 |
|
Atom 0.3 |
|
|
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|