← Prev in month ← Prev in thread
Next in thread → Next in month →

RE: [voting] BEA Systems Intentes to vote No on UBL Naming and DesignRules

From
Fulton Wilcox
Date
2004-12-13T15:16:00+00:00
ID
Thread
RE: [voting] BEA Systems Intentes to vote No on UBL Naming and DesignRules
MHonArc v2.5.0b2 -->

voting message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: RE: [voting] BEA Systems Intentes to vote No on UBL Naming and DesignRules

From: Fulton Wilcox <>

To: 'Hal Lockhart' <>, 

Date: Mon, 13 Dec 2004 10:15:48 -0500

Hal,

The points you advocate would seem to pass some risk and cost to transaction
recipients for non-standard extensions introduced and broadcast by
transaction senders. 

If I ran a business delivering packages to mountaintop sites accessible in
winter only by snowshoe, perhaps I would induce the customers to incorporate
a special "customer altitude" tag into their UBL orders to assist me with
pricing and scheduling. My own parser of course would of course need to
recognize and process that tag/payload. That would be a "private" extension
to this narrow community, and there is no reason to vote "no" to create
private community solutions.

However, what you seem to propose is that the senders in my hypothetical
case not only customize their environments to send that "private" tag and
content to me. They could thereafter incorporate that tag in all orders to
everyone they do business with, and under your proposal the recipients are
supposed to set up their technology to accept the transaction and ignore the
non-standard tags and payload. 

At a minimum, this approach clutters up the transaction stream with bits and
pieces of "private" content. 

Of course, under your proposal, I could also add a tag entitled "warranties
void in these jurisdictions" and incorporate the names of most UN member
countries in the payload. Under your proposal, the recipients would accept
the transaction without protest, because they would have set their parsers
up to ignore all non-standard tags and associated payload. Therefore, unless
the recipients implement some "check the extra tag" edits and reports, they
will have no way of knowing what extra tags and payload are being tossed
into the bit bucket.

Therefore, I suggest that your objectives are better addressed by a
combination of "front door" updates to the standard, plus genuine
customization capabilities that enables "private" extensions to stay
"private."

                                     Regards,

                                     Fulton Wilcox
                                     Colts Neck Solutions LLC
← Prev in month ← Prev in thread
Next in thread → Next in month →