[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] Actual version of the common core component paper
I do not have detailed responses to each of your questions but here are a few general comments that may help.
1. I believe some of your issues deal with the CCTS specification itself and not so much with the CCC document. In many cases, the specification limited the ways in which something could be implemented. It would be good to separate these issues and direct them to the CCTS Implementation Verification group.
2. There are some recommendations in the CCC document that do not conform to CCTS (e.g. additional attributes for CodeType, new CCTs). These were intended as proposed enhancements to CCTS v1.90 and should also be directed to the CCTS Implementation Verification group. I understand the confusion of including them in the CCC document and am proposing that they be removed from the document (Gunther - previously I had recommended that deviations from CCTS should be highlighted in a separate chapter but I now believe this information should be clearly separated from the core document and not intermingled with the main text).
3. This document originated as a UBL NDR project but has evolved into something larger. It is now a joint document between UBL and OAGI Core Components as well as the basis for an ATG2 project. Therefore, you may see some things that did not originate directly from LCSC.
4. Since this document deal with the XML Schema implementation of CCTS, you will see some things that may be specific to XML Schema. For example, one of your comments referred to DBMS or programming data types. Actually, these are XML Schema built-in types. Generic, functionally-oriented data types work fine for a logical data model but we need to have some way of expressing our use of these built-in XML Schema types.
I've also included a couple of UML class diagrams the correspond to the CCC document (not 100% but pretty close).
Hope this helps.
garret
Tim McGrath wrote:
In reformulating my comments about this paper, i realise that my original concerns were not addressed. Most of these still apply.What makes this discussion confusing for me is that the document is in a 'raw' state of editing. I am slowing unravelling what it means but the structure, narrative (or lack of), redundant headings and ambiguous examples don't help. I hope someone is planning to do some serious editing of this paper to fix the inconsistencies.
I still cannot see why Representation Term and Data Type are not synonyms. Why do we need both of these. For example, if we allow 2 different refinements of the secondary representation term, 'Day' where one is "monday" and the other is "28" (day of month) then we reduce interoperability and don't gain anything. These are two different semantic things and should be two separate secondary representation terms. In the paper the authors themselves confuse the two (4.1.2 and 4.1.5 are different definitions - i suspect there is a gDay mixed up in there and trying to get out). So if one representation (either primary or secondary) is one data type - why have two separate objects for these things, when they will always be the same?
To summarise my problems with applying this paper to the 0.80 models, I attach a copy of the CCTS diagram that describes Core Components and Data Types. I use this to orientate myself around the concepts described in the paper.
Using the meta-model from the attached diagram, I think I am correct is assuming that this paper...
a. describes the current CCTS Core Component type objects and proposes two new ones (Rate and URI)
b. describes the current data types of CCTS Secondary Representation terms objects and proposes several new ones (Day, Duration, Factor,Float,Int,Month, MonthDay, Number, PosInt,Year, YearMonth)
c. proposes 'common' aggregate core components (Period and Recurrence)My further questions are then:
With (a.) what is the rationale for these new CC types? For example, i was not aware that the Library Content has not identified a need for URI. Surely our proposals should be based on implementation experience? With respect to "Rate", the CCTS explicitly says to use "Numeric" for rates where the units are not included or are the same (i think this means things like rate of exchange, where the units are described outside the component itself as part of an aggregate) and "Quantity" for rates with counted co-efficients (e.g. km per hour). Therefore, Rate is either a secondary representation term for Numeric or Quantity. If we don't accept that Rate is a secondary representation term then why don't we have Percent (or other secondary rep. terms) as new CC types as well? Whilst we are talking of Percent - why is it used in 3.8.4 to decribe 'ValueType'?
There is a similar issue with (b). It appears some of these have originated from outside our Library - they look like DBMS or programming data types to me. From our models I would have expected things like, Description and Note (as secondary to Text), Size (secondary to Quantity or Measure), Weight and Volume (secondary to Measure). However, we tend to use these terms as Property Terms - so there isn't a major requirement to have them as secondary Rep. Terms anyway.
With (c) the question is why do we want these separated from other Core Components/BIEs in the Library. Surely, what makes a thing 'common' is how many times it is re-used not whether we call it common. For example, what about "Temperature" - it is re-used five times (like Period) in our library. Doesn't creating a new class of 'common core components' just create a maintenance problem with determine what is in it and what is not? [[NB By the way, when you describe "Recurrence", i think you mean "Frequency" - the rate of occurrence (or reccurrence). ]]
Tim McGrath wrote:
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-- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php
begin:vcard n:Minakawa;Garret tel;fax:650.506.7812 tel;work:650.506.3412 x-mozilla-html:FALSE url:www.oracle.com org:Oracle Corporation;e-Business Suite, ATG adr:;;500 Oracle Parkway, M/S 6op6;Redwood Shores;CA;94065;USA version:2.1 email;internet:garret.minakawa@oracle.com title:Director, e-Business Integration fn:Garret Minakawa end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]