|
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.
len
-----Original Message-----
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.
---- Stephen D Green
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.
---- Stephen D Green
On 21 June 2015 at 13:06, Costello, Roger L. <costello@mitre.org> wrote:
| ||||||