RE: [ubl-dev] SBS and Restricted Data Types

["David RR Webber \(XML\)" <david@drrw.info>]

Fulton, 

What implementers need to know is the delta, or if a delta exists 
betweeen what they have already and what their partner requires. 

In traditional EDI and XML it is "suck it and see" time.  Simply because
there is no 
standard approved way of exposing this in a consistent form. 

If you have that mechanism then suddenly you alter the equation! 

It no longer becomes a guessing game - if I send this transaction, will
it fail? 
What LOE will it take to get my system working with theirs? 

By exposing this all with tools like CAM you dramatically alter the
equation. 

Partners can examine your requirements, and even pre-test samples -
before 
they even cross the bridge of sending transactions to you. 

Schema cannot do this on its own.  In fact it fails pretty much out the
gate 
when it is a large schema - and I believe this is what we are grappling
here 
with SBS - not all these other nuances! 

Simply put - if I give you the schema - you still have *no clue* what a 

valid XML transaction will look like that my system can accept!!! 

Instead - you have to ask for a sample XML message as well - to know
what you 
are trying to do.  And that is iffy too of course.  More likely you will

need several samplers if its a large schema - based on context and role 
(that theme again). 

If this was all like a crossword puzzle - giving someone a schema is
like 
giving them the crossword - with little to no clues!!! 

So - we're back to the same conclusions - yes - you can significantly 
improve the adoption metrics here - by implementing the full solution 
stack that we originally envisioned for ebXML - where the registry 
provides a pivotal part, along with CPA, context, role, and templates 
of transactions (aka SBS) so that partners can quickly align with 
known patterns (CAM templates) based on knowing their context 
and role.  If they have a BPSS available - then they can find that 
even faster! 

DW

 -------- Original Message --------
Subject: RE: [ubl-dev] SBS and Restricted Data Types
From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
Date: Fri, May 05, 2006 1:22 pm
To: ubl-dev@lists.oasis-open.org
Cc: 'Chiusano Joseph' <chiusano_joseph@bah.com>, 'Stephen Green'
<stephen_green@bristol-city.gov.uk>

All:

There is an economic equilibrium between the costs of working within a
standard versus the cost of accommodating diversity. If implementing
standards become more convoluted, the equilibrium shifts in favor of
doing
n-way direct translations. 

Therefore, what Dave described as "the one way is the true way" and
"pure
UBL" has little to do with truth and a lot to do with minimizing cost of
adoption. If the number of particularities increases, the economic
equilibrium flips in favor of "pure particularity."

Probably any given particularity along the lines of Joe's original
message
(see below) is unlikely to trigger a shift in the economic equilibrium
cited
above. However, the accumulation of particularities and embellishments
can
have that effect. 

A further issue is that the "cost causers" who impose particularity
often
are not the "cost payers." For example, the hub in a hub and spoke
trading
relationship may impose particularities on what could easily be a "pure"
UBL
trading relationship. Of course, in response many prospective "spokes"
exhibit great agility in avoiding or delaying adoption.

Everyone involved in UBL has both a standards hat and one or more
"particularity" hats. In the interest of the standard, there needs to be
a
healthy level of impedance to bringing particularity inside the
standard.


Fulton Wilcox
Colts Neck Solutions LLC

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent: Tuesday, May 02, 2006 4:35 PM
To: ubl-dev@lists.oasis-open.org
Subject: [ubl-dev] SBS and Restricted Data Types

Please pardon me if this question has been asked before on this list (my
searches indicated the contrary):

In terms of the SBS, what is the best way (if any) to restrict data
types of a UBL schema for an specific implementation? Whether it is a
1.0 or 2.0 schema does not matter for purposes of this question (at
least I don't believe so).

For example, what if one had a need to define an xsd:minOccurs or
xsd:maxOccurs facet for an xsd:string data type, for their own
implementation?

Thanks,
Joe

Joseph Chiusano
Associate
Booz Allen Hamilton




---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the
UBL OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/