|
Juha,
Your note is very timely.
I'm scheduled to present on the 14th here in Wash
DC
on using CCTS + CAM and I really like how you have
structured your thoughts here - I will certainly
be
echoing this in the present - and I do plan to
share
those PPT slides and materials this week
with
everyone here too.
I would also add that I see ebXML registry
providing a vital cog here - in
orchestrating
the deployment of vocabularies and
dictionaries that can then be
automatically
referenced by tools such as CAM.
This is especially important given the
decision by CEFACT in October to
deploy
registries worldwide.
Empowering re-use by direct coupling
to
the runtime environment has always
been
a challenge - but 2005 is when I see
we
address this.
I shall be covering this in depth in the
materials on the 14th.
Thanks, DW
----- Original Message -----
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
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
|