[
Lists Home |
Date Index |
Thread Index
]
At 2006-02-12 12:42 +0000, Fraser Goffin wrote:
>It appears to be a common practice when, if you have a schema which
>includes a volatile code-list (enumeration), to externalise it into
>its own [chameleon] schema and then include that schema into the
>main [transaction] schema. I just wanted to see whether others have
>experience of using this approach and if any issues arise from it ?
We are abandoning that approach in the Universal Business Language
(UBL) schema expressions.
>In our case the enumerated values of of type xs:string (not sure if
>this matters but it might)
>
>We also get our schema from a standards body who define the standard
>market values. Naturally :-) my business colleagues are not always
>satisfied with that and want to both extend and restrict the values used.
Indeed ... it is particularly for the desire of extending, though
also conveniently for the need for restricting the values that
trading partners using our W3C schemas would not be successful if UBL
enumerated our code lists as sets of values in the schema expressions.
Code lists (also called controlled vocabularies) really do have a
life of their own.
>So in this case I am thinking of :-
>
>a. creating another schema to contain OUR custom enum values
>b. creating another schema that imports my custom codes and the
>market standard and :-
> - contains a type which is a restriction of the market standard enum
> - contains a type which is a union of the restricted market
> standard and custom enum.
>
>Does this seems reasonable ?
It didn't in our case ... the UBL W3C schema expressions are
sacrosanct. We want our users to be able to accommodate their needs
with UBL without touching the UBL schema expressions so they can
formally agree on the structures of their documents without risk of
inadvertently messing things up. We are undertaking a new position
where the schema expressions are going to be used solely for
structural validation, and then the code list value validation (as
agreed upon by trading partners) is a separate step. Then we went
the next step and formalized the expression of the members of the
code lists using some ground-breaking work in this area by Tony
Coates called genericode[1].
To see what we are doing, there is a draft of the UBL Code List Value
Validation Methodology[2] posted that I'm contributing to the UBL
committee, which uses genericode and describes a formalism with which
two trading partners can unamibiguously express their agreement on
which code list values to use where in their documents. I'm working
this week on a revision to be ready by Friday. I gather from the
reaction that a number of other projects are already considering
adopting this methodology, so you may find that it will fit with your
objectives.
But ... and this isn't palatable to everyone ... it isn't a
schema-oriented solution ... it is a Schematron-oriented solution ...
in effect the trading partners are asserting what code list values
are allowed to be where in their documents.
One last note ... the UN/CEFACT W3C Schema expressions of a few key
code lists (four in total) have indeed been brought into the UBL 2.0
schemas under development, thus constraining trading partners to
agree only on a restriction (if necessary) of those particular code
lists, not an extension. This is because the W3C Schema expressions
cannot be extended. Looking at the Naming and Design Rules for these
UN/CEFACT code lists[3] you will see that in section 9.1 that they
only provide for restricting code sets, not extending them. For the
*dozens* of other code lists in UBL we are providing an environment
where trading partners can unequivocally express agreed-upon sets of
values, and include such formal expressions in trading partner agreements.
We think this new approach solves a major issue in information
interchange involving controlled vocabularies, code lists,
enumerations, whatever you want to call them. I'm finding the work
quite interesting and satisfying. Stay tuned.
I'm submitting my conference paper on the UBL code list value
validation methodology at both XTech 2006 and XML 2006 and I hope
that it is accepted in order to bring out some discussion of these
points in public fora.
I hope this helps.
. . . . . . . . . . . . Ken
[1] - http://www.genericode.org
[2] - http://www.oasis-open.org/archives/ubl-dev/200512/msg00034.html
[3] - http://lists.oasis-open.org/archives/ubl/200601/msg00090.html
--
Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
|
