[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-clsc] UK Gov Codelist Requirements
Paul,
I believe we have alrady captured these requirements as noted below. Please see if there needs to be a change in wording to make this clearer.
Hope this helps,
Marty
In a message dated 1/28/2004 3:25:31 PM Eastern Standard Time, paul.spencer@boynings.co.uk writes:
As requested at today's telecon, these are the requirements extracted from 1.1.1 [R32] Support for describing the past and future time-variance of the valuesAn effective date and expiration date should be established so that the code list can be scoped in time. See, for example, “Patterns for things that change with time”, http://martinfowler.com/ap2/timeNarrative.html
1.1.1 [R17] Code lists must be unambiguously identified(1) - any two uses of the same URI represent the use of the very same code list definition (2) - no two differing code list definitions shall be represented by the same URI The business issue is that when two trading partners identify the use of a code list, there must not be any ambiguity. Should either partner create a code list or change an existing code list, the identification of the resulting code list must be distinct from that of its origin.
1.1.1 [R25] Documentation for individual values of a code listEach code value on the code list must not only contain valid values and decode values, but must also contain a long description which describes, in detail, the business meaning and usage for this code value.
1.1.1 [R30] Support for users to attach their own metadata to a code listEach code list must have the flexibility to have additional descriptive information added by an individual user to account for unique business requirements. 1.1.2 [R31] Support for users to attached their own metadata to individual values of a code listEach code value must have the flexibility to have additional descriptive information added by an individual user to account for unique business requirements.
Perhaps not a perfect fit for this, but the following requirement facilitates: [R30] and [R31].
I think this is covered by [R25] above or in the usage of code lists in
1.1.1 [R1] First-order business information entitiesAs first-order business information entities (BIEs). For example, one property of an address might be a code indicating the country. This information appears in an element, according to the Naming and Design Rules specification [NDR]. For example, in XML a country code might appear as: <Country> 1.1.2 [R2] Second-order business information entitiesAs second-order information that qualifies some other BIE. For example, any information of the Amount core component type must have a supplementary component (metadata) indicating the currency code. For example, in XML a currency code might appear as an attribute: <Currency code=”EUR”>2456,000</Country>
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]