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

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

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

-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Sunday, December 12, 2004 6:48 PM
To: voting@lists.oasis-open.org
Subject: [voting] BEA Systems Intentes to vote No on UBL Naming and Design
Rules

BEA Systems intends to vote No on making UBL NDR an OASIS Standard once the
voting period commences on December 16th. Our reasons are contained in the
comment below which we will post with our No vote. We are posting this
message to the organizational voting list to make our intentions known to
the voting members as we realize only TC members are likely to examine the
votes which have been cast.

Hal Lockhart
Organizational Representative - BEA Systems, Inc.


----------------------------------------------------------------------------
-------------------
BEA Systems votes no on UBL Naming and Design Rules v1.0 as an OASIS
Standard.  BEA commented during the public review that we believe that
distributed extensibility and versioning is a key architectural component of
distributed systems and UBL should allow for distributed extensibility [1].
The UBL TC responded to the effect that exchanging business documents where
one side did not have the extension schema - what we have called distributed
compatible extensibility - is not in business interests because both sides
must understand any extensions for continued exchange.  We believe that this
requirement - that all parties in an exchange must simultaneously deploy new
schemas and semantic understanding - is too onerous for business scenarios.
There is a long history of compatible evolution of business documents that
could be formalized and fostered by UBL.  We are very concerned that this
design will lead to very tightly coupled and brittle business systems. We
are also concerned that this specification will act as an undesirable model
for other specifications.


1] http://lists.oasis-open.org/archives/ubl-comment/200410/msg00000.html
----------------------------------------------------------------------------
-------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: voting-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: voting-help@lists.oasis-open.org