[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: VS: [ubl-dev] UBL's role
Answers inline: Juha Ikävalko wrote: >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? > DN - I do not have enough data , but would presume it makes sense based on similar adoption scenarios with other XML languages that are not used as internal data formats. > 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. > > DN - Most software manufacturers adhere to something called MVC. Model-View-Control. This precludes making your application dependent on any specific data model. The danger of making an application dependent upon UBL is that if UBL changes, your application will not work. YOu should have a solid core set of functions working on tokens that represent values from UBL instances and read those in via some sort of UBL tokenizer class. If UBL changes, you only have to change the tokenizer (also referred to as marshalling) class, not the core logic. >(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? > DN - XML parsers will check for both well formed-ness and validation with general accuracy. David RR Webber has found some things that you can engineer that XML schema cannot validate consistently, but none of those things exist in UBL in its' current rendition (please correct me if I am wrong). > 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. > > DN - read up on MVC. It is a bad idea to ever do this. >(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. > DN - think beyond "documents". Architecturally, a document is only a collection of data instances and becomes a document when presented and viewed as such. >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. > > DN - XML and XML schema have nothing to do with semantics. Schema only constrains structure. Logic is kept separate from XML instances. XML is a declarative markup language, not a programming language. To do those things, there are a number of different ways you can implement it. You could simply transform and slurp all things UBL-ish into an SAP system or you could use a CAM application balanced on a crate of Ricards Red. There are no constraints and each individual is free to implement their own "behind the firewall" as they see fit. Duane > >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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]