I usually see a "Code" a precise kind
of identifier issued by an organization to identity a specific
domain or thing.
The "ID" is true that is generally an identifier within a domain (e.g the Invoice ID is an identifier in the "380" Invoice domain code),
but IDs are a more general concept that embraces all uses including the "code" case.
I believe UBL has provided a specific "Code" information item for specific trade purposes, while IDs are availale by design almost every where in all documents.
So I would see a more severe semantic violation if you put an ID into a Code information Item than the opposite.
I hope this is an acceptable explanation.
At least this worked very good with all the real application/instances I have created.
Cheers,
Roberto
Il 12/05/2015 18.38, Duvekot, Kees ha scritto:
The "ID" is true that is generally an identifier within a domain (e.g the Invoice ID is an identifier in the "380" Invoice domain code),
but IDs are a more general concept that embraces all uses including the "code" case.
I believe UBL has provided a specific "Code" information item for specific trade purposes, while IDs are availale by design almost every where in all documents.
So I would see a more severe semantic violation if you put an ID into a Code information Item than the opposite.
I hope this is an acceptable explanation.
At least this worked very good with all the real application/instances I have created.
Cheers,
Roberto
Il 12/05/2015 18.38, Duvekot, Kees ha scritto:
All, 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"? 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) And it looks like this use of Language as an ID instead of a code already goes back to UBL 1.0 .... 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:CodeTypeI 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 --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2015.0.5863 / Database dei virus: 4342/9753 - Data di rilascio: 12/05/2015
--
Best regards
Roberto Cisternino
JAVEST By Roberto Cisternino
P.IVA: IT01290640117
C.F.: CSTRRT68M06E463H
Document Engineering Services, Director Associate
OASIS Member
TESISQUARE Partner
Mobile: +39 328 2148123
Skype: roberto.cisternino.ubl-itlsc
Best regards
Roberto Cisternino
JAVEST By Roberto Cisternino
P.IVA: IT01290640117
C.F.: CSTRRT68M06E463H
Document Engineering Services, Director Associate
OASIS Member
TESISQUARE Partner
Mobile: +39 328 2148123
Skype: roberto.cisternino.ubl-itlsc