Re: [ubl-dev] Basic Invoice - How Names Are Linked / Determined

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

At 2009-06-19 10:34 +1000, jaymuz@optusnet.com.au wrote:
>I'm nearly there. Thanks for your answers.
>
>A bit of clarification on what is following what here [if any] with 
>regards names.
>
>1. The tag name <tagname></tagname> is taken from ref attribut value 
>"cac:InvoicePeriod" even though the element name is "InvoicePeriod" 
>in cac [as otherwise namespaces wouldn't function. Correct?

I'm unclear what the "ref attribute value" but per namespaces, 
"InvoicePeriod" is the local name and spelling of an element, using a 
dictionary metaphor, in the 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" 
language.  So when you look up that word in that dictionary you get 
that dictionary's meaning.

The "cac:" is an expression artefact and has no meaning at all in 
UBL.  For consistency in documentation, it happens to be the 
namespace prefix proxy to the 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" 
URI string ... but "sally:" would have worked just as well.

Note this dictionary metaphor is quite useful because UBL does happen 
to have two words spelled the same "Location" but coming from 
different dictionaries: 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" 
and 
"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2". 
In each language (dictionary) there is a different meaning for 
"Location".  These could have been referenced with the prefixes 
"sally:" and "harry:" and they would all still interoperate with 
someone happening to use the prefixes "cac:" and "cbc:".

>2. In this line in Invoice:
><ccts:DictionaryEntryName>Invoice. Invoice_ Period. 
>Period</ccts:DictionaryEntryName>
>
>To determine what should be after Invoice_ Period. we look for the 
>ObjectClass tag of the next level in this case the complex type 
>definition. Correct?
>
><ccts:ObjectClass>Period</ccts:ObjectClass>

Yes ... but you are trying to do this analysis from the schema ... 
most people do it from the definitive spreadsheets found in this directory:

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

A growing number of people are finding Crane's free hyperlinked HTML 
summaries of the spreadsheets more useful than the spreadsheets themselves:

   http://www.CraneSoftwrights.com/resources/ubl/index.htm#ubl2modelreport

>3. If that be the case then where do we get the string "details" in:
><ccts:DictionaryEntryName>Period. Details</ccts:DictionaryEntryName>

In the spreadsheet (or the HTML rendering of the spreadsheet).

>and the string "Date" in:
><ccts:DictionaryEntryName>Period. Start Date. Date</ccts:DictionaryEntryName>

In the spreadsheet (or the HTML rendering of the spreadsheet).

Note that collaboration within the UBL TC is done by way of the 
spreadsheet (and some members use UML diagrams).  The schema 
artefacts are synthesized from an analysis of the spreadsheets.  The 
schemas are not created by hand ... there is no human intervention 
other than invoking the process.  The process is defined by UBL's 
Naming and Design Rules (NDR) ... NDRs are an OASIS innovation now 
being used by many other organizations including UN/CEFACT.

I hope this helps.

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

--
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal