OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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,

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 
>
>  
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]