[
Lists Home |
Date Index |
Thread Index
]
At 2006-02-13 12:26 +0000, Fraser Goffin wrote:
>some 'at first glance' questions. If these seem a bit dumb, please
>take them as an oppotunity to promote the strengths of this approach :-
All questions are welcome, Fraser!
>1. How does this approach specifically assist in dealing with
>versioning issues ?
Code list versioning is a shared responsibility between describing
the code list, associating the code list, and using the code
list. UBL provides code list meta data attributes that a user can
choose to use. genericode provides for indicating the version of an
expression of code list values.
In a UBL instance a user can say the following, indicating that the
version of the code they are using is not important to them:
<cbc:AccountTypeCode>ABC</cbc:AccountTypeCode>
Alternatively, if the version is important they could say:
<cbc:AccountTypeCode listVersionID="3.7">ABC</cbc:AccountTypeCode>
A genericode expression of values includes the version of those values.
A code list context association file could have the union of a number
of genericode files that trading partners wish to use:
<Context item="AccountTypeCode" codes="atcV3-6 atcV3-7"/>
My scripts will check the authored content for a version number and,
if not present, will check the value given against all values of all
associated code lists (since version isn't indicated, all are in
play). When present it will limit the checks against only the code
list with the same version number as @listVersionID. If no
associated genericode code list has the version number indicated in
the UBL instance, then the value violates the constraints expressed
in the triad of description, association and use, and an error is reported.
>2. I see mention of auditability and impact analysis but didn't
>understand how these would be acheived. ?
Could that have been in another document? I don't mention either of
those terms explicitly in my document. I think my discussion above
regarding sensitivity to versions of code lists would handle
auditability. I'm not sure what you mean by impact analysis.
>3. How is this approach 'better' than creating a vocabulary schema
>for each third party contract using the 'chameleon' schema +
>xs:redefines/union/restrition etc. I mentioned earlier (I take the
>point about being able to specify particular contexts in which an
>enumeration can apply - but is there more ?)
By not conflating value validation with structural validation.
I am in the camp that believes if you change the schema for a
document you have to change the version of the schema. If you change
the version of the schema, you change the namespace of the
document. Otherwise, two trading partners could inadvertently be
saying "I use UBL 2.0" when they are, in fact, using different sets
of schemas that are indicating the same namespace URI string.
By layering value validation on top of structural validation,
business constraints on values don't impact on the declared structure
of the document.
Now one could say they have the same problem saying "I'm using the
following association files" when in fact they are not ... but that
is a management issue in that they interchange the layer on top of
the standardized W3C Schema expressions. Which then leads to the
question of "why not just interchange the agreed on W3C Schema
expressions? ... how is that different?"
I believe they really are different ... structural schemas are
(should be in my opinion) inviolate. Granted some inviolate
enumerations are required by UBL *by design of UBL* and are not
subject to trading partner interpretation. Not all enumerations are
business related code lists. I do believe that a structural schema
can express an enumeration of values that are inherent in the design
of the information structure.
It is the purview of the UBL committee to dictate the structure of
UBL documents for interoperability of the instances. It is the
purview of trading partners to agree on the layer of value validation
placed on top of the standardized structures that are under their
control in doing business. They do not have the authority to mess
around with the fixed enumerations designed in as part of UBL's
internal design.
I believe if trading partners have to "compromise" the standardized
structures by building in the business rules of value validation,
they run the risk of having different schema expressions expressing
the same "structure of a UBL 2.0 document". With careful management
it can surely be done ... but I'm concerned about the integrity of
saying "my modified W3C schema expressions conform to UBL 2.0 ...
trust me!" With my proposed methodology I can categorically say "I
am using the sacrosanct UBL 2.0 document structures" and then just
focus on ensuring you and I agree on the layer of value validation
placed on top.
By not conflating business rules with standardized structure, the
standards committee's efforts to produce a set of structures to be
used by all is incredibly enhanced because nobody has to touch them
in any fashion in order to become fully interoperable at a business
level as well as a structural level. And the enumerations needed in
the design of UBL not related to business rules remain sacrosanct and
trading partners cannot extend them and possibly break UBL
implementations (though they could be restricted if trading partners
wish to agree on subsets of UBL invocation somehow).
YMMV in this regard, but it is a position I have long held (for good
or ill) and I always try to find ways to deal with read-only
distributions of agreed-upon issues.
Finally, one could refute the above with a pure W3C Schema approach
stating "well, I'll use inviolate UBL 2.0 for a W3C Schema first pass
and then my favourite W3C Schema method of implementing code list
values in a modified W3C Schema second pass for code lists" ... all
power to you, but I think the elegance in genericode expression and
management, and the flexibility in associating sets of values with
contexts is easier to manage, easier to understand, and easier to
introduce into a trading partner agreement.
Oh, one more thing ... my approach allows two different contexts of
the same information item to have two different sets of coded values
(see the example in sectoin 6.1 regarding the "item-b" information
item) ... how could I do that with W3C Schema expressions when they
do not support co-occurrence constraints? I'm effectively saying
that element item-b (which is globally declared in UBL) has two sets
of values (two types) based on its parent.
>4. Large lists are still a problem right ?. It is not unusual in the
>financial services sector for many lists to be > 200 entries, a
>reasonable number to be > 1000 and a few that are >10,000. Using
>schematon XSLT would be a bit impractical wouldn't it ?
Would two trading partners have to agree on all 10,000 being
available to engage in business?
Would such number constraints be less impractical in a W3C expression
of 10,000 enumerations?
A genericode file could be synthesized from a database query of which
of the 10,000 would be appropriate for a particular department or
line of business. I suppose a database query could also synthesize a
W3C Schema fragment.
Note that XSLT is but one implementation of ISO/IEC 19757-3
Schematron ... now that it is ratified as an ISO standard vendors
might explore more high-speed implementations and customers with
requirements to support 10,000 values being validated might pressure
vendors to consider finding high-speed solutions to such issues.
>4. You mentioned in your earlier response to Glen, that you had
>hoped in UBL to remove ALL embedded enumerations from schema.
Indeed ... the presence of any embedded enumeration constraints of
business-related concepts when using this methodology would only give
benefits of agreeing on a subset of the declared list rather than a
flexible list of any set of values.
>Did you decide then that no enumeration could be considered 'stable'
>or did you want this just to keep the approach consistent regardless
>? (you also mention 'type 1' code lists which suggest in schema definition ?)
The former ... that no enumeration could be considered stable for the
long run. Business has been flexible for thousands of years ...
introducing constraints on what two trading partners wish to agree
upon seems arrogant ... I anticipate trading partners to be far more
imaginative in doing business than UN/CEFACT or UBL or anyone could
bring down by edict.
I hope this helps. Thanks again for your questions!
. . . . . . . . . . . . . . . Ken
--
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
|
