Re: [ubl-dev] UBL's role

[Duane Nickull <dnickull@adobe.com>]

Juha:

UBL is a "wire format" language. The most common scenario will be that 
"A" and "B" want to do business. A has some internal application that 
has its own internal data format, so does B. However, in order that A 
can send B some information that B understand, A serializes it into UBL. 
The advantage of doing this if there are only A and B is limited, the 
real gain is when they start talking to C, D, E, F, G etc. too.

IMO - it is highly unlikely that UBL instances will persist behind a 
firewall other than for archive purposes. When a UBL instance arrives, 
it will most likely be "transmogrified" (C & H term) into the naive data 
format of choice or simply serialized and stored into a DB.

If the incoming UBL is to be presented to a human, there is no limit on 
how it may be presented (HTML, PDF, Java Swing app, VB app).

Not sure what CAM adds in this scenario since XML schema can handle most 
of what is needed for UBL.

Duane



Juha Ikävalko wrote:

> Hi UBL Developers,
>
> I’ve been thinking about the role of UBL in real implementations. I 
> don’t have prior experience of a vocabulary based implementations thus 
> excuse me if these are irrelevant issues from UBL’s viewpoint.
>
> I see a UBL schema as a skeleton of a real business document as it 
> doesn’t define any constraints (facets) to data types.
>
> First I thought that one should derive own schemas (xsd aware ways 
> through restriction/extension, facets) from UBL schemas to meet real 
> business needs. I would describe this as a “high coupling” model where 
> all business/context rules are contained in a single document schema 
> (through namespace imports). Of course, rule-based conditions should 
> be satisfied by using some rule-based schema language, such as Schematron.
>
> After reading (and hopefully understanding) the response which David 
> RR Webber gave me a month ago 
> (http://lists.oasis-open.org/archives/ubl-dev/200411/msg00017.html) I 
> came to second thoughts:
>
> The purpose of UBL schemas, vanilla + derived (industry/country 
> spefic) schemas, is “only” to define the overall (superset) structure 
> (skeleton) of business messages for certain needs. Business rules 
> (flesh & blood) should be defined in separate schemas which are not 
> necessarily constrained by UBL customization rules. (It’s enough that 
> instance document is a valid UBL document.) Thus the solution which 
> would satisfy the real business needs would consist of series of 
> separate validations which could be reach by a combination of UBL 
> vanilla + derived schemas + Schematron or by using validation 
> frameworks such as CAM and DSDL. I would describe this as a “low 
> coupling” model with series of separate filters (vanilla, industry, 
> country, company, trading partner).
>
> Hopefully my previous description was understandable and relevant. I 
> would appreciate if someone could share his/her view of how to model 
> these things. Links to good articles would be also very valuable.
>
> Regards,
>
> Juha Ikävalko
> TIEKE Tietoyhteiskunnan kehittämiskeskus ry
> TIEKE Finnish Information Society Development Centre
> Salomonkatu 17 A, 10th floor
> FI-00100 Helsinki
> Tel +358 9 4763 0410, Fax +358 9 4763 0399
> juha.ikavalko@tieke.fi <mailto:e@tieke.fi> http://www.tieke.fi
>

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Chair - OASIS eb SOA TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
***********