[
Lists Home |
Date Index |
Thread Index
]
At 2006-02-12 10:56 -0600, Greg Alvord wrote:
>Thank you, this look very interesting. MISMO has been struggling with three
>identified use cases for enumeration management.
Many organizations have similar requirements.
>1) Lists which MISMO manages for the real estate finance community. For
>example there needs to be a standard list of values and definitions for the
>kinds of amortization. Loans are given, mortgages bought sold and
>aggregated into financial instruments. Everyone needs the same industry wide
>definition.
In UBL examples of these are: AcknowledgementResponseCode,
DocumentStatusCode, etc. ... we define a base set of these values and
provide them to users as a baseline on which the can build.
>2) Lists that are managed by an external central authority. For example the
>UN list of value codes for countries, languages, currency etc.
In UBL we have adopted four from UN/CEFACT: CurrencyCode_ISO_7_04,
LanguageCode_ISO_7_04, MIMEMediaTypeCode_IANA_7_04, and
UnitCode_UNECE_7_04 ... these come down from on-high.
>3) Lists which are external to MISMO but have no central management either.
>For example the scoring model product names of all the providers of credit
>scoring service.
In UBL examples of these are: AccountTypeCode, CardTypeCode, etc.
... trading partners figure these values out for themselves and we
don't have any guidance because they could be anything.
>We have never had a good solution for cases 2 and 3. The approach you have
>documented may be a solution to those use cases.
>
>If I understand correctly UBL is planning to use this methodology in case 1
>as well.
It is indeed ... we came to the conclusion not to use
schema-expressed enumerations for any of our code lists, but then
determined we are (unfortunately) obliged to use schema-expressed
enumerations for the lists from UN/CEFACT.
This allows UBL users to extend or restrict lists of your cases 1 and
3, but only restrict lists of case 2 (which is why it seems
unfortunate to have to use the UN/CEFACT schema expressions).
Note in the methodology how the second pass is only viable after the
first pass is successful ... the second pass is based on XPath
addresses, thus mandating the structural integrity of the instance,
thus requiring the schema validation of the instance to pass ... if
we included enumerations in the schema expressions for cases 1 and 3,
they could not be extended because the extended values would violate
the constraints of the first of the two passes. That is why in UBL
we cannot extend the lists from UN/CEFACT.
>We will look at it fo possible inclusion in our version 3.x architecture.
Kewl! I would be most anxious to hear of this methodology being used
in other situations so that feedback returned from other deployments
might improve the guidelines for all.
Note that the scripts included with the examples work with *any*
document model and with enumerations expressed in genericode ... it
will work with enumerations expressed otherwise by changing only the
genericode-specific components ... otherwise, the methodology is
generic. UBL is used only as an example of its use, the methodology
is not dependent at all on UBL.
Thank you for your comments!
. . . . . . . . . . . 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
|
