[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] code list categorization for 2.0
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]