ubl-lcsc message
[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
- From: "Stuhec, Gunther" <gunther.stuhec@sap.com>
- To: "'Tim McGrath'" <tmcgrath@portcomm.com.au>
- Date: Wed, 25 Jun 2003 15:53:27 +0200
Title: Message
Hello
Tim,
I
putted my answers into both mails.
Kind
regards,
Gunther
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.
[GS:
I'm still looking for someone who helps me to do this serious editing.
If you have some time, it would be very glad if you can help me. That would
be an advantage, because you found the inconsistencies and you need some
more helpful information. Please start with me to do this
work.]
I still cannot see why Representation Term and
Data Type are not synonyms.
[GS: If you look into the
CCTS than you'll see that all Representation Terms will be based on Data Types.
That means, you have to define a Data Type
whereby the secondary representation term will be the qualifier of this
data type, for example "Date_ Date Time. Type". If you defining a BCC or BBIE with a representation term, like Date, this must
be based on the Data. Type "Date_ Date Time. Type" but you put into the
dictionary entry name the qualifier as a representation term only, like "Order.
Creation. Date".]
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.
[GS:
Why do we reduce the interoperability. For example, if you would like that your
charlady have to do the regular cleaning-out every Wednesday and if you would
like to pay her the money on every 28th day of the month, how you would like to
express this information by using the current CCTs?]
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).
[GS:
the definition should be clear definition of the secondary representation term
itself and the chapter "Details and Value Ranges" defines the clear semantical
and technical representation of each component (content component and
supplementary components. It based on the CCTS specification. Sometimes it could
be same information as in "Definition". If you look in the CCTS in more detail
you'll see that the CCTS using sometimes the similar definition for the CCT
and the Content Component.]
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?
[GS: The problem is the technical definition and the specific
characteristics. For example "Day" has another structure as well as another
characteristics as "Date Time", therefore it is necessary to define two
different types.]
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)
[GS:
That is right, you have to define a new CCT if you need a type with
different supplementy components as the existing ones.]
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)
[GS: That is right, all representation terms be based on one data
type. If we're using this proposal or this schema structure, than we
well
c. proposes 'common' aggregate
core components (Period and Recurrence)
[GS:
That is right. I defined some very basic aggregate core components, we can add
some more]
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?
[GS:
For example "Person. EMail Address. Text", it should better, if we're using for
the expression of the e-Mail address itself the URI-conventions. But you can not
express this conventions in detail by one of the existing CCTs. Therefore I
defined a new one called "URI. Type". You can use this one for "EMail Address",
than the BCC will be "Person. EMail Address. URI" and you can express the
address itself in the conventions of SMTP, X.400 etc. without any
problems.]
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.
[GS: Rate can be used for the ratio of quantities or measurements. I
guess it is more elegant to doing this with one CCT which have at least two
supplementary components, the unit itself and the base unit. Because if you
would like to express this by using the current CCTs, you have to do the
following one:
Quantity. Rate. Details
Rate. Quantity [with the supplementary component
"Unit. Code"]
Rate. Base Unit. Code
You
see, for this expression is no representation term "Rate" necessary. I guess
this is a very elementary information and it makes sense to express this
information by a new CCT like "Rate. Type". If you would like to express the
exchange rate of currencies for example, you need a bunch of information like
first amount with specific currency and second amount with specific currency and
additionally the date of the exchange rate. I guess, it is the best if we're
expressing that information by using a specific ACC. For this is a secondary
representation term named "Rate" not necessary, too.]
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'?
[GS:
"Percent can be one value without any additional (supplementary)
information, like "unitCode". Therefore "Percent" can be a secondary
representation term, which will be based on "Numeric. Type. I have to describe
"Value. Type", I will do that soon.]
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.
[GS: I
have no problem, if we're agreeing that this proposed secondary representation
terms will be used as property terms. But important is, that we have to
define specific data types for the information, because all specific information
will be based on specific characteristics (built-in datatypes). Addtionally, we
have to define very clearly when a specific information would become a secondary
representation term or a property term. Normally the terms "Day", "Year",
"Month", "Duration" etc. will be unique information and will be based on "Date
Time. Type" only. For the definition of BCC/BBIE it makes more sense, to have
this terms as secondary representation terms, because than you can define the
dictionary entry names more effectively, like the weekly: "Magazine. Delivery.
Day"] which will be based exactly on the structure of the day in a week.You can
not define a secondary representation term for "Size" or "Description". becuase
you can use this information with more than one CCT like "Size. Quantity" or
"Size. Measure" or "Description. Quantity" or "Description. Text". It gives
always different semantic meanings.]
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). ]]
[GS:
There was an issue in NDRSC to define the most frequent possibilities for
expressing date and time information. I resolved this issue together with Mike
Adcock. We created the specific Date. Types for the possibilities for expressing
the points of date and time. Furthermore, we have seen that we have to express
the period and the recurrence in a common way. Because many people doing that in
many different ways. We defined two ACCs for it, it called "Period. Details" and
"Recurrence. Details". If you like, I can send you the working papers and the
results of our discussion. Because I didn't found to place this two ACCs in our
NDR-spec, I putted this results into this Common Core Components
paper.]
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?
[GS:
That is right]
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?
[GS:
Taht is right]
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.
[GS: Garret Minakawa divided the schemas into two parts:
CoreComponentType.xsd and DataType.xsd. All data types based on one
specific core component type but it have some restrictions. You can express
this restrcitions in XML schema by using other built-in data types, by using
addtional facets or by the restriction of attributes
itself.]
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".
[GS:
The data type is "Currency_ Code. Type". But in the CCTS is not very
clear how you can use the qualifier of the data type in the BCC/BBIE. On the
one hand side, we can use this qualifier as a property and on the other hand
side we can use the qualifier as a secondary representation term. The CCTS
needs more wording about it. I made a comment for
it.]
How do we make the leap from Data Type to Core
Component Type?
[GS: Normally if you have a reusable basic type which will
be in a restricted form of a CCT, than you have to define a new Data Type
for it.]
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.
[GS:
We have to fix this problems]
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?
[GS: Yes.]
PS why does 1.3.4 have yet another
interpretation of Code/Identifier when we have already a position paper on
this?
[GS:
I guess this was the nearly same interpretation from Mike Adcock. Or I'm
wrong. Could you send me the exact
interpretation.]
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]