FW: [voting] BEA Systems Intentes to vote No on UBL Naming and Design Rules

["Hal Lockhart" <hlockhar@bea.com>]

Forwarded on behalf of David Orchard in response to comment by Fulton
Wilcox.

-----Original Message-----
From: David Orchard 
Sent: Monday, December 13, 2004 3:48 PM
To: Hal Lockhart
Subject: RE: [voting] BEA Systems Intentes to vote No on UBL Naming and
Design Rules


This is why we have also proposed that incompatible extensions can be
marked with a "mustUnderstand" flag to require the "warranties void" tag
be understood.  The significant difference between the "mU" approach and
the current UBL rules is that UBL does not allow a 3rd party create the
"warranties void" tag and require others understand, UBL requires that
UBL standardize this tag.  

Cheers,
Dave

> -----Original Message-----
> From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com]
> Sent: Monday, December 13, 2004 10:16 AM
> To: Hal Lockhart; voting@lists.oasis-open.org
> Subject: RE: [voting] BEA Systems Intentes to vote No on UBL Naming
and
> Design Rules
> 
> 
> 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