[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] udt:IdentifierType vs. udt:CodeType
Hi Folks In short, I remember it was decided, for simplicity, that it is a 'code' when there is a codelist; otherwise it is an 'identifier'. Regards Steve ---- Stephen D Green On 13 May 2015 at 02:22, Tim McGrath <tim.mcgrath@documentengineeringservices.com> wrote: > You may be amused to see the discussion paper from 2002… > > > https://lists.oasis-open.org/archives/ubl-lcsc/200206/msg00023.html > > On 13 May 2015, at 01:23, G. Ken Holman <gkholman@CraneSoftwrights.com> > wrote: > > At 2015-05-12 16:38 +0000, Duvekot, Kees wrote: > > If you look into other elements with UBL you will see other instances where > they same question can be raised (Identifier vs code). The first thing that > comes to my mind is related to Tax where there is a TaxCategory/ID where you > use "Tax codes" and you also have a "TaxTypeCode" as part of the TaxScheme. > Even the CEN BII Tax Guidelines are showing that you should use a specific > code list to populate the ID field of TaxCategory. But I'm sure there are > other too. > > It is also sometimes difficult to distinguish between them .. when does a > "code" become an "identifier" or when is an "identifier" a "code"? > > > Yes, that is an important question. The line is very blurred. Pretty well > any argument for one can be considered an argument for the other. > > In my book on code lists I try on page 11 to highlight that some identifiers > could easily be codes and some codes could easily be identifiers ... the > book is available for free download on a "try and buy" basis at > http://www.CraneSoftwrights.com/training/#pcli ... if you decide not to pay > for the book, please delete the copy that you download for free. > > There I talk about, generally but not always, a code represents a > characteristic and an identifier represents a lookup value. Codes might > typically be standardized across all users and applications while > identifiers might typically be custom to a subset of users or only a single > user with a database lookup (e.g. product identifiers). > > But not always. One could very easily lookup codes in a database table. > > Is it a "LicensePlate ID"? ... or a "License Plate Code"? or even License > Plate Number? That consists of alphanumeric characters :-) > Is if a Postal Code ? or a Postal zone Identifier? > > As long as we all "understand" what we mean and expect in a field ... then > it does not really matter how it is called .. (but it helps in the initial > thinking about the field .. and that is why we try to make clear distinction > where even possible) > > > I observe that the supplementary component metadata for Code. Type is > different than that for Identifier. Type, so this might be input for someone > trying to choose: > > http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#UDT-Code.Type > > http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#UDT-Identifier.Type > > And it looks like this use of Language as an ID instead of a code already > goes back to UBL 1.0 .... > > > Perhaps for the same reasons I cited for UBL 2.x. And I think that was all > that the original poster was focused on. > > . . . . . Ken > > Kees Duvekot > > -----Oorspronkelijk bericht----- > Van: G. Ken Holman [mailto:g.ken.holman@gmail.com] Namens G. Ken Holman > Verzonden: dinsdag 12 mei 2015 13:28 > Aan: Eric Desgranges; ubl-dev@lists.oasis-open.org > Onderwerp: Re: [ubl-dev] udt:IdentifierType vs. udt:CodeType > > At 2015-05-12 11:58 +0200, Eric Desgranges wrote: >>We're back on our project re. UBL implementation. I notice a language >>code will translate into an identifier type whereas a country code is >>based on a code type. What are the rationales for that distinctive >>implementation? >> >>cac:LanguageType -> cbc:IDType -> udt:IdentifierType OR >>cbc:LanguageIDType -> udt:IdentifierType cac:CountryType -> >>cbc:IdentificationCodeType -> udt:CodeType > > I believe this distinction comes from inheriting into UBL the design > concepts chosen by UN/CEFACT. > > I don't think there is any discussion about the use of country "codes" ... I > think the focus of this question is why the Identifier Type is chosen for > the language value. Forgive me if I'm mistaken as I'm not trying to put > words into your mouth. In my work as chairman of the OASIS Code List > Representation Technical Committee, this was my focus on your question. > > Note the CCT components of the Core Component Types for Code and Text in > section 8.1 of the Core Components Technical Specification V2.01 (pages 96 > and 97): > > http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS_V2-01_Final.pdf > > For both of those core component types you will find the component > "Language. Identifier". It was not the UBL committee that chose the name of > this supplementary component. > > You can see these components realized in the attributes of UBL for the > unqualified data types of Code, Text and Name (since Name is derived from > Text) as "LanguageID": > > http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#UDT-Code.Type > http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#UDT-Text.Type > http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#UDT-Name.Type > > Since UBL is using CCTS, thus it is using "Language. Identifier", or > languageID=, for its attributes, it would be inconsistent to be using > "Language. Code" for its elements at the same time. Yes I know attributes > are different from elements, and elements carry all of their own CCT > metadata, but I think we would be getting "distinctive implementation" > questions if we used identifier in an attribute and code in an element for > the one concept of language. > > At the time the UBL committee decided to work with UN/CEFACT core component > types my focus on the committee work was elsewhere, so there may be other > rationale that contributed to the answer to your question, but this is my > own perspective of the answer that I've developed from my analysis of the > situation. > > I hope this is helpful. > > . . . . . . . . Ken > > > > -- > Check our site for free XML, XSLT, XSL-FO and UBL developer resources | > Free 5-hour lecture: http://www.CraneSoftwrights.com/links/video.htm | > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ | > G. Ken Holman mailto:gkholman@CraneSoftwrights.com | > Google+ profile: http://plus.google.com/+GKenHolman-Crane/about | > Legal business disclaimers: http://www.CraneSoftwrights.com/legal | > > > --- > This email has been checked for viruses by Avast antivirus software. > http://www.avast.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > ----------------- > Regards > Tim McGrath > tim.mcgrath@documentengineeringservices.com > Fremantle, Western Australia 6160 > AUSTRALIA > Phone: +61438352228 > Skype: t.mcgrath > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]