[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [ubl-dev] UBL's role
|
FYI,
Juha's note the UBL dev list today.
I see this as a good summary - but I'm
adding to this ebXML registry - and
using
same to provide runtime access to
domain
dictionaries for automatic rule
referencing.
Thanks, DW
----- Original Message -----
From: Juha
Ikävalko
Sent: Monday, January 10, 2005 6:14 AM
Subject: [ubl-dev] 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]