[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] [code] updated Catalogue and some draft schemas
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. >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]