Re: [ubl] More code list questions about NDR, and about genericode

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2005-10-11 17:27 -0400, G. Ken Holman wrote:
>Work is progressing well, but I've hit a snag not realizing naming 
>and design rules about the naming of metadata properties for code 
>list values.
>...
>My quandary is figuring out the automation of which code list 
>attributes are to be tested for which information items based on codes.
>
>(1) why does @amountCurrencyID have only 
>@amountCurrencyCodeListVersionID and not others such as 
>@amountCurrencyCodeListAgencyName?
>(2) why doesn't @quantityUnitCode have 
>@quantityUnitCodeListAgencyName and not others such as 
>@quantityUnitCodeListVersionID?
>(3) why don't the meta data attributes of CountrySubentityCode have 
>any prefix at all and just have "@codeListName"?
>(4) why do I use only "amountCurrency" when prefixing 
>"CodeListVersionID", as contrasted with using "quanityUnit" when 
>prefixing "CodeListAgencyID" ... is the rule I remove the last "ID" 
>or "Code" from the information item name before adding the suffix?
>
>I've looked in NDR Section 6 of cd-UBL-NDR-1.0Rev1b.pdf under "Code 
>Lists" without any clues to the answers to the above questions.
>...
>I note five identification items in genericode, so I assume I map 
>them as follows:
>
>   genericode ShortName  ==  UBL xxxxxCodeListID
>   genericode LongName == UBL xxxxxCodeListName
>   genericode Version == UBL xxxxxCodeListVersionID
>   genericode CanonicalUri == UBL xxxxxCodeListURI
>   genericode CanonicalVersionUri == UBL xxxxxCodeListSchemeURI
>...
>My problem is now down to the naming of the meta data attributes.
>
>Would the following be acceptable?
>
>(1) for @xxxxxID remove "ID" and suffix with "Code..." from 
>genericode table above as appropriate
>(2) for @xxxxxCode remove "Code" and suffix with "Code..." from 
>genericode table above as appropriate
>(3) for <xxxxx> suffix with "code..." from genericode table above as 
>appropriate

Not hearing any response, I'll proceed with the above, but document 
the minor limitations that would only affect an XPath expert that 
goes beyond the objectives we have here of making a system easy to 
understand between trading partners.

If anyone does have an opinion on the above, please share your 
thoughts ASAP as I would not like to do this twice as a result of not 
having all the input.

Thanks!

. . . . . . . . . . Ken

--
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/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal