[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UBL's role
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]