Re: [ubl-lcsc] Actual version of the common core component paper

[Tim McGrath <tmcgrath@portcomm.com.au>]

Title:

Gunther, etc al..

Firstly, congratulations on having a position paper that needs a lever-arch
file to hold it.  you have raised the bar for us all  :-) 

However, I need some help with interpreting this document.  I am trying to
apply it to the 0p80 draft spreadsheets and have encountered some difficulty
understanding what you mean by it all.  

1. Am i correct in assuming that section 1 is clarification of the existing
Core Component Types from the CCTS?
 2. Am i correct in assuming that section 2, Proposed Core Component Types,
are not to be used in 0p80 (as per NDR decision), but may be used for demonstration
and feedback into CCTS?

However, the biggest issue I have is trying to understand the relationship
between all these terms.  I am afraid unless this paper presents its application
to the UBL library is a more consistent and coherent way, I dont see how
we can use it.

To give some examples...

a. In your examples using the UBL spreadsheet model you do not have a column
in the for "Core Component Type" instead you use the term "Data Type".  The
CCTS says,
"A Data Type must be based on one of the Core Component Types, but may include
restrictions of the set of values of that Core Component Type’s Content Component
and/or Supplementary Component(s)."  so these are not the same thing.  

It seems to me that the example in 1.3.9 that has,
Qualifier of Data Type = "Currency"
Data Type = "Code. Type"
UBL Definition = "identifies the currency using a code. ISO 4217-3 is recommended"

 - could be said to have a Core Component Type of "Code.  Type" and a Data
Type of "ISO4217-3. Code.  Type" or maybe "Currency. Code.  Type".

How do we make the leap from Data Type to Core Component Type?  

b. Some of the Schema examples seem to have more information (meta-data)
than the spreadsheet examples. For example, 3.1.7 (Example of secondary representaiton
terms) the term "Date" has Data type of  "Date Time.  Type" in the spreadsheet
and this magically appears as "DateType" in the Schema.  Are you assuming
that the XSD complexTypes are taken from the Representation term?  either
way this is really confusing, as i would expect the DateType in the schema
to reference the primary DateTimeType.

I am prepared to accept that this paper makes sense to someone, but to apply
it i need a simple chart that shows the meta-data needed in the UBL models
and what permissable values they can have.  Can anyone help me out with this?

PS why does 1.3.4 have yet another interpretation of Code/Identifier when
we have already a position paper on this?

Stuhec, Gunther wrote:

Hello all,

I uploaded the actual version of the common core component paper on our UBL webside. You'll find the paper here: http://www.oasis-open.org/apps/org/workgroup/ubl/ubl-ndrsc/download.php/2316/draft-stuhec-ccc-11.doc

Dear LCSC-colleagues could you review this paper and could you use the common core components for the reusable types, please. If you'll find any mistakes or if you have some further comments, send it to me please.

It is possible to hand in the recommended CCTs RateType and URLType as well as the enhancements of IdentifierType and CodeType to the CC Working Group as a part of the implementation verification process?

Kind regards,

        Gunther

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160