VS: [ubl-dev] UBL's role

[Juha Ikävalko <juha.ikavalko@tieke.fi>]

Thanks Duane,

I understand and mainly agree with you. I would still like to have a few additional answers.

(1) I agree with you. That's probably the most common scenario in the case of existing business process (and system). However, is it the most common scenario for the first UBL based implementations? As general, why to fix something, which isn't broken? Wouldn't it be the easiest way to implement a UBL based system at the same time you are implementing a new process? After having a handful of positive experiences you are probably ready to move forward.

(2) Again, I agree with you in the case of existing business process where you have data validation already implemented. However, in case of a new business process, wouldn't it be good to validate a received message before doing any processing? Wouldn't it be easiest to have business rules presented as a schema than "hard-coded" into the system? I'm not an expert, but I suppose it's easier to update a schema than a business application. Of course, there maybe some fundamental rules which I'm not aware of. In a case there is, I would be eager to learn.

(3) Yes, that's I'm aware of.

(4) Ok, I'll try to phrase UBL's role with my own words:
"UBL's objective is to become a standard message format for a horizontal exchange of B2B documents. UBL provides a wire format for business documents by describing a STRUCTURE of common business documents and SEMANTICS of each element. Thus UBL does NOT take any position or give any recommendations how business rule-based constraints (pattern, EndDate is greater or equal to StartDate etc.) are being handled. Those have been implemented, already, in current systems or should be negotiated separately." Am I on the right track? If yes, then I guess that XML Schema is perfectly enough for what UBL is meant for. CAM/Schematron/DSDL has its own meaningful purpose to handle those tasks which are not been addressed by UBL.


Are we on the same map or should I buy a new one?


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  http://www.tieke.fi


-----Alkuperäinen viesti-----
Lähettäjä: Duane Nickull [mailto:dnickull@adobe.com] 
Lähetetty: 10. tammikuuta 2005 19:21
Vastaanottaja: Juha Ikävalko
Kopio: ubl-dev@lists.oasis-open.org
Aihe: Re: [ubl-dev] UBL's role

Juha:

(1) 
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.

(2)
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.

(3)
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).

(4)
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
***********