Re: [ubl-lcsc] [code] updated Catalogue and some draft schemas

[Chin Chee-Kai <cheekai@softml.net>]

Stephen,

>>AllowanceChargeReasonCode, CancellationReasonCode, 
>>OrderRejectionReasonCode

Combining these codes into a neutralized code name such as
"ReasonCode" sounds reasonable as a generalization technique.
It could point to the start of a "UBL External Code List
Implementation Guideline" where we step back and look at
the overall implementation strategy and treatment of 
external code lists (lists whose values are defined and
owned by non-UBL agencies, but whose values are needed for use
within UBL).

What follows are referencing external code lists, unless
otherwise specified.

This example quoted above seems to me to reveal more the
code list type identity issue as talked about in previous
LC (Tue) call.  Do we give an external code list a new
type identity (implemented as a new namespace value) within
the context of their usage?
Do we give an implemented subset of an external code list
a new type identity?

For the 3 code lists given above, we seem to have said "yes"
to both questions.  That will be the most specialized case,
where the code lists values can change independently
without affecting one another.  Contextualizing the 
code list into the usage context would, from the 
code list implementation point of view, allow a reduction of
value range, thereby shortening the number of values within.
For example, if the reason codes for AllowanceCharge
are tangential to those of Cancellation, it is possible
(but not mandatory) to remove those codes of Cancellation
from the value range of AllowanceChargeReasonCode, thus
exercising the flexibility given by the independency of
the implemented code lists.

If we don't exercise this flexibility, and declare instead 
that the 3 code list usages should share the same set of 
code list values given by an external list, then we would
have a value range that would be a union of the value ranges
of the 3 sets of code list values.  It could either be
implemented as duplicated schemas (as Anne has observed)
if we want to keep the context of usage embedded in the 
implementation (and observed as having usage-oriented names 
like "AllowanceChargeReasonCode", "CancellationReasonCode" 
when they share the same code values),  or implemented as 
a "context-free" code list (and observed as having a neutral 
name like "ReasonCode")

We should keep in mind that in trying to align to external
code lists, we're on a reacting mode since external code values
and their value ranges are fixed.  We have very few means
of doing so, and probably could ask ourselves if we want
to use the list, or not.  In the case where there appears
to be only a partial fit, the second question (is a subset
a new list) will kick in as well.  Let's think through
this a bit.

That said, from implementation and packaging point of view, however,
I tend to think that combining and removing code lists from
the CLC (CodeListCatalogue) at this point in time may be too 
drastic an operation because it would, as you pointed out, 
require combing through to get new model drafts and then 
generate new sets of schemas (codelists, reusable and maindocs).



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Wed, 22 Oct 2003, Stephen Green wrote:

>>The answer to the multiple uses of the same codelist would be to change the 
>>model spreadsheets to use just one prefix for all three reason codes, then to remove
>> two of the code entries from the catalogue and rename the remaining entry 
>>'ReasonCode' provided there is no other code called 'ReasonCode'.
>>
>>This of course would need another draft - 
>>and if we are actually inclined to do this I'd put in a bid now to reconsider the three 
>>channel type BBIEs in Contact (email, phone and fax) and add them instead as value to the
>>ChannelCode codelist along with pager and SMS. This would allow proper reusability of the
>> library ABIE 'Communication' - quite an important ABIE for potential future reuse.
>>
>>All the best
>>
>>Steve 
>>
>>>>> Anne Hendry <anne.hendry@sun.com> 22/10/03 09:18:30 >>>
>>- AllowanceChargeReasonCode, CancellationReasonCode, 
>>OrderRejectionReasonCode
>>  Created 3 new "Stock" schema files, one for each code, all using the 4465
>>  values found at http://www.unece.org/trade/untdid/d03a/tred/tred4465.htm.
>>  Wasn't sure if there was a mechanism in place to reduce this type of
>>  duplication when using the same code values for multiple codes,
>>  but let me know if so - it's easy to remove the files.
>>
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.
>>
>>