OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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
 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]