RE: [ubl-dev] udt:IdentifierType vs. udt:CodeType

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

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