introduction to the type udt:IdentifierType

Hi,

I'm new to the UBL-specification and would like to understand the udt:IdentifierType which is used in e.g. the element cbc:ID in UBL-Invoice2.xsd. The type is derived through the common basic component.xsd.

Can someone give me some basic understanding how this type should be used? What does the different attributes schemeID, schemeName, schemeAgencyID, schemeAgencyName, schemeVersionID, schemeDataURI, schemeURI stand for? If possible please add values for these attributes to show usage of it.

 

thanks in advance!

 

niklas bergkvist

Good morning!  Your comment is best posted to UBL-Dev ... please see http://www.oasis-open.org/mlmanage/ for how to register.

There are two possible interpretations for your question "how this type should be used?" as in semantically or syntactically.  Given your follow-on questions I'll assume you are asking syntactically.  Semantically, the element that uses this as its base type is used to convey information in context of its parent, and the UBL documentation for each element describes how the element should be used.

As for how its attributes should be used, this ends up being a controlled vocabulary question.  An identifier in an identifier list is a controlled value just as a code in a code list is a controlled value.  Similarly an identifier value might be based on a scheme rather than a list (consider, for example, ISBN numbers are identifiers that are based on a scheme ... though of course a particular inventory of ISBN numbers could be used as a list).

The attributes you cite are instance-level metadata attributes.  The creator of the document chooses to use these attributes to qualify the value in the instance with metadata telling the recipient of the document more information about the identifier value.

To continue my example, if I were identifying my code list and UBL books in an instance, I might choose to use the following:

<cac:Item>
  <cac:Description>Practical Code List Implementation (First Edition)</cac:Description>
  <cac:StandardItemIdentification>
    <cbc:ID schemeID="ISBN">978-1-894049-22-1</cbc:ID>
  </cac:StandardItemIdentification>
</cac:Item>
<cac:Item>
  <cac:Description>Practical Universal Business Language Implementation (Third Edition)</cac:Description>
  <cac:StandardItemIdentification>
    <cbc:ID schemeID="ISBN">978-1-894049-23-8</cbc:ID>
  </cac:StandardItemIdentification>
</cac:Item>

If I've documented to my customers that the scheme identifier "ISBN" is the International Standard Book Number, then that tells the recipient I'm using ISBN numbers.  I might also use schemeName="International Standard Book Number" to be more explicit.

If there are different versions of the same scheme and my value conforms to only a particular version (or the semantics of how the data are interpreted changes based on the particular version), I would use schemeVersionID="".

To identify who is responsible for the scheme I would use schemeAgencyID="" and schemeAgencyname="".

Scheme identifiers and names are not standardized, but one could probably find standardized values for scheme URI strings.  Then I would use schemeURI="" to identify the scheme unambiguously.

If I wanted to convey where the data of a list of identifiers are kept, I would use schemeDataURI="".

Note that although the UBL TC has supplied genericode 1.0 files only for codes:

  http://docs.oasis-open.org/ubl/os-UBL-2.0-update/cl/gc/

... genericode can also be used to express lists of identifiers.  In an genericode file, the list's list-level metadata is used to qualify an instance's value by using the corresponding instance-level metadata attributes.

I hope this helps.

. . . . . . . . . . . . . Ken

Thanks for the explanation! As I understand this will make the schema really robust and backwards compatible.

While I will use some of the UBL-spec xsd's internally between our own systems I need to create something like the generic-code-list-document to get the different systems really loose coupled.

br niklas

Yes, I think you've said this quite well.

And in UBL 2.1 we are removing all hardwired code lists, even those from the base data types, in order to promote better interoperability and to support business requirements regarding code lists.

Using genericode and context/value association trading partners can tailor their UBL documents to use only the codes they agree upon.

I look forward to hearing about your success.  But I urge you to post to UBL-Dev rather than to this forum.

Good luck!

. . . . . . . . . Ken

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I