[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] code list categorization for 2.0
Resending as my first post appears to have been blocked by oasis due to the html contentt. -A Anne Hendry wrote: > Hello Saito-san, > > Thank you for all your excellent suggestions! It is helpful to have > the ECALGA example. Yes, I agree this would be appropriate for UBL to > provide in a guideline for code list use. Some of this documentation > could begin now, as it doesn't rely on any of the code list > architectural changes. Let's discuss at the TC meeting and see when we > might be able to produce this type of information. > > Thanks again, > Anne > > Yukinori Saito wrote: > >>Dear Anne Hendry, >>Thank you very much for your detailed reply. >>I understand the general situation regarding Codes in UBL V1.0. >> >>I think that some guidebook will be needed regarding Codes in UBL BIEs. >>In the current UBL specification V1.0, UBL Users (like JPLSC) are difficult >>to understand the specification regarding Codes.. >>When we will adopt UBL business document, we will study BIEs to targeted >>business document. There are some Codes BIEs in the business document. >>Next step, we will study some documents which explain the contents of Codes. >>Unfortunately, there are only 8 Code Lists in UBL V1.0 package. We don't >>know how to define or use the Codes which are not specified in UBL V1.0 >>package. >> >>If UBL TC will provide some guidebook regarding Codes in UBL BIEs, it will >>be very useful for UBL users. >>The contents would be followings. >>(1) General explanation >>- Policy to Code and Code List in UBL specification. >>- Guideline to define User's favorite Codes. >>(2) Code Lists Information per every Code (approximately 40 codes) >>Examples are followings. >>[Category 1 (Specified in UBL Specification)] >> <Code> <Specification> >>- DocumentStatusCode UBL-CodeList-DocumentStatusCode-1.0.xsd >>- LatitudeDirectionCode UBL-CodeList-LatitudeDirectionCode-1.0.xsd >>[Category 2 (Specified outside UBL)] >><Code> <Issuer> <URL of Specification> >>- CountryIdentificationCode ISO3166 >>www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.h >>tml >>- PaymentMeansCode UN/ECE4461 >> http://www.unece.org/trade/untdid/d03a/tred/tred4461.htm >>[Category 3 (Not specified by UBL nor others. These codes are specified by >>trading partners themselves on business.)] >><Code> >>- RejectActionCode >>- ShortageActionCode >>- UnitTypeCode >> >>[Related Information] >>One of very popular business documents is ECALGA by JEITA in Japan. >>ECALGA has about 50 business documents. >>And ECALGA has about 100 Codes, which are commonly used in 50 business >>documents, or seldom used in 50 business documents. >>ECALGA provides Codes List that specifies all Codes. >>The ECALGA's Codes List is very simple. The contents in the Codes List is >>Code Name, Code Length, and Definition (Value and Meaning). >>If the Code is defined outside ECALGA (JEITA), there is reference >>information. For example: Refer to JIS SX0304-1999. >>The ECALGA's Codes is written by MS Word, and the document size is only 11 >>pages. >>Of course, the ECALGA's Codes List is written in Japanese language. >> >>Best Regards, >>Yukinori Saito >> >>----- Original Message ----- >>From: "Anne Hendry" <Anne.Hendry@Sun.COM> >>To: "Yukinori Saito" <saito-yukinori@fujielectric.co.jp> >>Cc: <ubl@lists.oasis-open.org> >>Sent: Thursday, August 25, 2005 3:59 AM >>Subject: Re: [ubl] code list categorization for 2.0 >> >> >>Hello Saito-san, >> >>Appologies for the long delay in responding. Your questions raise larger >>questions. Here is my perspective on where we stand with respect to the >>entire list of codes referenced in UBL for which you are asking >>clarification. >> >>To start, my opinion is that we should only distribute UBL code lists >>that UBL owns, otherwise: >> >>- we will be in a very difficult position (and so will our users) when a >>code list owner revs a code list between UBL versions, even worse when >>multiple code list owners rev multiple code lists beween UBL verisions, >>resulting in the possibility that our releases would be driven by code >>list owner revision timetables >> >>- we can't anticipate what code lists a user wants to use, so even if we >>do ship a couple of very common code lists, a user will undoubtedly need >>more, so why do this part-way approach >> >>- we blur the line between codes we own and codes others own, causing >>confusion down the line; we will be viewed as being reponsible for the >>codes we ship whether or not we own them >> >>UBL, obviously references/defines many code lists. The only lists we >>'handled' in 1.0 were the ones we though would be necessary to achieve >>this 'out-of-the-box' scenario. These are more fully documented in the >>'Specialized' ss. But that included lists like country and currency >>code, which we don't own. >> >>I think we create problems when our 'out-of-the-box' solution includes >>distributing values for code lists we don't own. I believe some degree >>of configuration will always need to be done - that there is no true >>complete 'out-of-the-box' no-config-needed scenario, no matter what code >>list values we ship. >> >>If we can arthictect a simple method for users to get those >>needed-for-out-of-the-box, but not-owned-by-ubl code lists, and only >>include in our packages the code lists that are truly owned by UBL, that >>to me would be the best way forward. Otherwise we create a maintenance >>problem as we continue to verson UBL, and code list owners (not UBL) >>continue to version their code lists. We should instead provide an easy >>mechanism for users to add their favorite code lists to UBL when they >>configure their system. >> >>In response to question on the many code lists in UBL 1.0, the >>description of those code lists is in the 'Definitions' column of the >>1.0 spreadsheets wherever they are used/defined (eg. Reusable). We only >>expanded the information on codes we wanted to be present for that >>out-of-the-box scenario. We never went beyond this with the rest of the >>codes - it wasn't thought necessary at the time. I agree it may be >>useful, where we have the information, to document which international >>codes lists would most likely be used to supply those values when one >>went to use that abie, but this is really up to the trading partners to >>decide within their own context. The only codes UBL is bound to define >>are the ones we created (eg.AcknowledgementResponseCode) - the ones to >>be found in the Specialized datatypes ss in 1.0. >> >>We can put the task of adding documentation for the other codes on our >>task list, but it falls lower on the priority list, obviously, than >>getting the code list architecture sorted out. >> >>I think we should modify the scope of the out-of-the-box scenario to >>only include the code lists we actually create/own (at most, the 8 >>listed in category '1a' in >>http://lists.oasis-open.org/archives/ubl/200508/msg00096.html, plus ones >>we find we need for ubl 2.0). >> >>We should leave the decision of inclusion and use of others code lists >>(eg. currencyCode, countryCode, quantityUnitCode, etc) up to the user, >>where the decision rightly belongs, but make it as easy as possible for >>them to do this through the new code list architecture. >> >>I hope this helps answer some of your questions, >> >>-Anne >> >> >> >>Yukinori Saito wrote: >> >> >> >>>Dear Anne Hendry, >>>Thank you very much for your categorization of the UBL V1.0 code lists to >>>Category 1 and 2. >>>I understand the followings. >>>- 8 code lists in UBL V1.0 code lists are defined in UBL. And the values >>> >>> >>are >> >> >>>defined at the CodeLists XML Schema. >>>- 5 code lists in UBL V1.0 code lists are defined outside UBL. I understand >>>the values and definitions of these code lists according to the original >>>standard documents that you informed the URL. >>>Thank you very much for your spreadsheet named >>>'UBL-CodeListCatalogue-1.0-beta' >>>I understand that there are many Codes in UBL BIEs. >>>This spreadsheet is valuable for UBL users to understand information >>>regarding Codes. (e.g. What kinds of Codes are there in UBL business >>>documents? Where the values of the codes defined?) >>> >>>Dear Jon Bosak, or Anne Hendry, >>>I understand your approach regarding the 13 Code Lists that UBL V1.0 >>>provided values at the CodeLists XML Schema. >>>But I cannot understand the remaining Codes (approximately 40 codes) in UBL >>>V1.0 business documents. >>>The examples of the remaining Codes in UBL V1.0 are followings. >>>- CommodityCode >>>- ContractTypeCode >>>- CoordinateSystemCode >>>- DespatchAdviceTypeCode >>>- DispositionCode >>>- EmergencyCardCode >>>- EmergencyProceduresCode >>>- ExemptionReasonCode >>>- HandingCode >>>- HazardousPackingCriteriaCode >>>- InvoiceTypeCode >>>- Others >>> >>>For UBL users like JPLSC, we needs the contents definitions (values) about >>>these Codes. >>>Are there some documents that describe the values of these Codes? >>>If yes, would you please clarify the explanation of Code Lists? >>>If no, are there some policy and schedule to make those code lists >>>documents? >>> >>>Best Regards, >>>Yukinori Saito >>>(Vice chair of UBL JPLSC) >>>------------------------------------------- >>>Yukinori Saito >>>Fuji Electric Information Service Co., Ltd. (FIS) >>>e-mail: saito-yukinori@fujielectric.co.jp >>>Tel: +81-3-5435-7333 Fax: +81-3-5435-7513 >>>------------------------------------------- >>> >>> >>> >>>----- Original Message ----- >>>From: "Anne Hendry" <Anne.Hendry@Sun.COM> >>>To: <gkholman@CraneSoftwrights.com>; "David Kruppke" <kruppke@gefeg.com> >>>Cc: <ubl@lists.oasis-open.org> >>>Sent: Tuesday, August 16, 2005 7:25 AM >>>Subject: [ubl] code list categorization for 2.0 >>> >>> >>>Hi, >>> >>>Following up on my AI ... >>> >>>Below, in Category 1a, #s 1-8, and Category 2, #s 1-5, are the 13 Code >>> >>> >>Lists >> >> >>>UBL provided values for in 1.0. The categories are based on Tony's paper >>>from >>>http://lists.oasis-open.org/archives/ubl/200508/msg00043.html and >>> >>> >>subsequent >> >> >>>F2F discussion. >>> >>>I've separated Category 1 into 'a' and 'b', reasons below. >>> >>> >>>Category 1a >>>----------- >>> >>>Codes that are created and owned by UBL or unlikely to change between UBL >>>major releases. >>> >>> >>>1. UBL-CodeList-AcknowledgementResponseCode-1.0.xsd >>> >>> Values: OrderResponseComplex, OrderResponseSimple >>> >>> >>>2. UBL-CodeList-DocumentStatusCode-1.0.xsd >>> >>> Values: Cancelled, Disputed, NoStatus, Revised >>> >>> Notes: >>> UNECE also defines a 'Document Status Code'. >>> See http://www.unece.org/trade/untdid/d03a/tred/tred1373.htm. >>> We did not use these values because they did not fit our use of D.S.C. >>> Rather, UNECE 'Status Description Code' was closer to what we wanted. >>> See http://www.unece.org/trade/untdid/d00a/tred/tred4405.htm. >>> Our 'Document Status Code' overlaps, not duplicates, tred 4405. >>> >>> >>>3. UBL-CodeList-LineStatusCode-1.0.xsd >>> >>> Values: Added, Cancelled, Disputed, NoStatus, Revised >>> >>> Notes: >>> Same as DocumentStatusCode, but with additional value: 'Added'. >>> >>> >>>4. UBL-CodeList-LatitudeDirectionCode-1.0.xsd >>> >>> Values: North, South >>> >>> Notes: See LongitudeDirectionCode. >>> >>> >>>5. UBL-CodeList-LongitudeDirectionCode-1.0.xsd >>> >>> Values: East, West >>> >>> Notes: >>> UNECE defines Latitude Degree >>> (http://www.unece.org/trade/untdid/d03a/tred/tred6000.htm) >>> and Longitude Degree >>> (http://www.unece.org/trade/untdid/d03a/tred/tred6002.htm) >>> as part of 'Additional Location Information' >>> (http://www.unece.org/trade/untdid/d03a/tisd/tisdals.htm) >>> and 'Geographic Details' >>> (http://www.unece.org/trade/untdid/d03a/ticd/ticde008.htm). >>> However, none of these specify North/South/East/West, >>> presumably derived by context. >>> North/Souht/East/West, however, is all we needed. >>> >>> >>>6. UBL-CodeList-OperatorCode-1.0.xsd >>> >>> Values: Divide, Multiply >>> >>> >>>7. UBL-CodeList-SubstitutionStatusCode-1.0.xsd >>> >>> Values: Original, Substitution >>> >>> >>>8. UBL-CodeList-ChipCode-1.0.xsd >>> >>> Values: Chip, MagneticStripe >>> >>> Notes: >>> This came from Mike Adcock, I believe and we didn't have a standard >>> code identified for it. I think it's one for which we should be using >>> a standard code, though, and move it to Category 2, as I see additional >>> values that identified with these two values when searching through >>>codes, >>> and this just seems quite far afield for something for UBL to maintain. >>> We'd have to find the right standard code, though. >>> >>> >>>Category 1b >>>----------- >>> >>>Codes that are owned/provided by ATG2. >>>These are the only ones I see from most recent schema delivery: >>> >>>- Currency >>>- Language >>>- MIMEMediaType >>>- Unit >>> >>>If I've missed something we'll need to re-evaluate, but ... >>> >>>The only one of these we use is Currency, but we had discussed this as a >>>category 2. It's not clear to me that any of these should go into >>>category 1, >>>as I believe they are codes that are outside of UBL purview and can change >>>without UBL agreement, and may very well change in between UBL releases. >>>I think these should all be put as Category 2. >>> >>> >>>From David Krupke: >>> >>> Due to using the ATG2-UnqualifiedDatatype schema module there is a change >>> concerning the currency code list. ATG2 has a predefined code list for >>> currency codes. We assumed that the UBL CurrencyCodeType and >>> >>> >>UBLAmountType >> >> >>> should also use this predefined code list. In order to do this we had to >>> change the values for code list agency and code list name. As a result >>> CurrencyCodeType is now located in the SpecializedDataType schema, >>> >>> >>because >> >> >>> it does not have an own simpletype for the content. I think this would >>>be a >>> good chance to do this in general, to store all specialized data types in >>> the SpecializedDataType schema including the code lists. This would be >>> >>> >>the >> >> >>> same behavier like ATG2. Another item is to get rid off UBLAmountType. >>> It is now redundant. >>> >>>Anne: >>> >>>I was under the impression that these 'common' .xsd files would be coming >>> >>> >>>from ATG2 (CCT, CCP, UDT and possibly SDT depending on what we needed). >> >> >>>But the diffs I see are: >>> >>>- the new CBC now has our UBL-defined codes >>>- SDT has CurrencyCode and AmountType; it used to only have AmountType >>>- Unspecialized DataTypes is now Unqualified DataTypes >>>- besides code lists there are several new files in the 'common' directory >>>- there is no CCT >>>- CCP is the same >>> >>> >>>I think it would be helpful at this point to have a mapping from UBL 1.0 >>>common files to UBL 2.0 common files so we >>> >>>- know where the line is drawn between ubl files and atg2 files, >>>- can align names of the remaining files, >>>- can understand what if anything should be kept in the ndrs >>> in reference to any of the resulting files in 'common' >>> >>>Regarding 'AmountType', I'm not sure why it was created, >>>so Tim should take a look and comment on that move. >>> >>>Separately, regarding schemas, David is suggesting we put all code lists >>>in SDT. >>> >>> >>>Category 2 >>>---------- >>> >>>Codes that are created and maintained external to UBL, >>>some likelihood of changes between UBL releases. >>>UBL has no control over whether or when they change. >>> >>> >>>1. UBL-CodeList-AllowanceChargeReasonCode-1.0.xsd (UN/ECE 4465) >>> >>> Values: See http://www.unece.org/trade/untdid/d03a/tred/tred4465.htm. >>> >>> Notes: >>> Appears to be exact duplicate of UNECE 4465 code, >>> 'Adjustment reason description code'. >>> We call it 'AllowanceChargeReasonCode' though. >>> What is the impact of changing the name of the code to match 4465? >>> >>> >>>2. UBL-CodeList-ChannelCode-1.0.xsd (UN/ECE 3155) >>> >>> Values: See http://www.unece.org/trade/untdid/d03a/tred/tred3155.htm. >>> >>> Notes: >>> Appears to be exact duplicate of the UNECE 3155 code, >>> 'Communication address code qualifier'. >>> We call it 'ChannelCode, though. >>> What is the impact of changing the name of the code to match 3155? >>> >>> >>>3. UBL-CodeList-CountryIdentificationCode-1.0.xsd >>> >>> Values: See >>> >>>www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1. >>> >>> >>h >> >> >>>tml >>> >>> Notes: >>> We only use the first part of iso 3166 (3166-1). >>> iso 3166-2 has the country subentities but we didn't implement that. >>> >>> >>>4. UBL-CodeList-CurrencyCode-1.0.xsd >>> >>> Values: See >>>http://www.bsi-global.com/British_Standards/currency/index.xalter. >>> >>> Notes: >>> In the latest schemas from David, this is now in the SDT. >>> See note under ATG2 codes (category 1a). >>> Further discussion is probably needed on these. >>> >>> >>>5. UBL-CodeList-PaymentMeansCode-1.0.xsd >>> >>> Values: See http://www.unece.org/trade/untdid/d03a/tred/tred4461.htm >>> >>> Notes: >>> Exact duplicate of UNECE 4461 'Payment Means Code'. >>> >>> >>>Further considerations: >>> >>>- This breakdown doesn't take into account that some of the category 2 >>> >>> >>codes >> >> >>> will be coming from gefeg. Don't know if we need to make that >>>distinction. >>> >>>- In looking at this again, going back to the original lists of codes we >>>have >>> in our models, these were only the beginning - the codes we though we had >>> to define in order to achieve a positive out-of-the-box experience. >>> >>>- The attached spreadsheet has a complete list of codes as they were in 1.0 >>> Beta. I'm not sure if we should, before 2.0, look at these again and if >>> we don't add any more codes to the UBL codes, possibly give some guidance >>> on how to use the codes for which we don't point to un codes or give >>>values. >>> >>>- We seem to be going back to a twist on the original model we had where >>> we provided xml files with the code values (placebo, etc). This is >>> in some ways comforting, in others disconcerting. I can't recall the >>> issues raised in that implementation that caused us to pull it, but I >>> believe the schema template will solve that problem. >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe from this mail list, you must leave the OASIS TC that >>>generates this mail. You may a link to this group and all your TCs in >>> >>> >>OASIS >> >> >>>at: >>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe from this mail list, you must leave the OASIS TC that >>>generates this mail. You may a link to this group and all your TCs in >>> >>> >>OASIS >> >> >>>at: >>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> >>> >>> >> >> >>--------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. You may a link to this group and all your TCs in OASIS >>at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]