ubl-lcsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl-lcsc] Modeling Core Component Types
- From: Tim McGrath <tmcgrath@portcomm.com.au>
- To: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
- Date: Fri, 13 Feb 2004 08:56:39 +0800
see comments inline...
CRAWFORD, Mark wrote:
Tim,
Some thoughts for you -
The UBL Library has been built upon a set of data types/core
component
types defined by the CEFACT CCTS v2.0 specification.
To date, we have relied upon hand crafted schemas to define
these. This
has resulted in a few problems...
a. the schemas have to be mapped to the representation terms
in the UBL models.
b. they have not always bewen synchronized with other deliverables
c. the provide a disjointed view of the overall UBL library.
both the CCT and Unqualified DT schema modules are in fact normative expressions of CCTS to be used by anyone - not just UBL and not just for the UBL library. The recent change to mapping to DTs rather that RTs would seem to eliminate this aspect of the problem. The focus should be on creating the UBL qualified DT schema module as an expression of the LC content model.
none of that impacts on the three points made above.
* when people study the UBL library they find spreadsheets and UMl diagrams
of all the structures except the CCTs.
* we still have to map our BIEs to specific CCTs/DTs (or whatever they are
called today). Today this means taking a Representation Term and tracking
into into XSD to find the things it contains.
* we do not present a conceptual view of the entire library.
So what we are talking about is at one level documentary support for the
Library. At another level it will also give us the mechanism to model any
UBL DTs (if we want them).
I personally think that generating XSD schema off these is a pragmatic alternative
to the hand crafting until we get an official ATG2/CEFACT set of schemas
to work from. But this is debatable.
To this end I have dug into the CCTS specification and
created a model of the Core Component Types - both as a UML Class Diagram and a UBL
format spreadsheet model. These are attached. My objective was to
create structures that modelled the Dictionary Entry Names in the
specification.
I like the idea of the model and it would be a welcome addition to the CCTS, but am not convinced that yours is 100% accurate. As I look at the CCTs defined in Table 8-1 of CCTS, there appear to be many inconsistencies in terms of both class and subclass as expressed in your model. I would also like to see a separate UML model of the UBL qualified DTs.
I accept I may not be 100% because I am working like a detective, making
assumptions based on clues in Table 8-1. That is why i would appreciate
someone telling, but I did base this entirely on table 8-1 and 8-2. Can
you be more specific as to where it is inaccurate? (NB I don't know what
a subclass is :-[ )
My biggest thread of evidence was the Dictionary Entry Names. These have
Object Classes that imply associations with the 'type'.
I should emphasise that this model reflects what the CCTS 2.0 tables 8-1 and
8-2 define.
I have not designed anything, i am just documenting for the benefit of those
trying to make sense of the CCTs - but I had to force myself not to start
refining.
If the CCTs are going to be maintained then this material should give plenty
of fodder for some rationalisation and good data modeling.
PS i have a suspicion that someone, somewhere has the original model - in
fact they must have used something similar to build the component library.
i am happy for you to use my reverse engineered one - but it may pay to
put out a call to the original authors.
PS this exercise exposed a few typos (i suspect) in the
specification so
few objects have slightly different names.
Please identify the typos so I can fix the CCTS.
In Table 8-1
- the CCT Component Quantity. Unit. Code - i suspect was supposed to be Quantity
Unit. Code (ie the object class is Quantity Unit not Quantity) - this keeps
it consistent with the remaining components and with the way it was modeled
for Measure Type. This carries into table 8-2 as well.
similarly
- the CCT Component Identification Scheme Agency. Identifier was possibly
meant to be Identification Scheme. Agency. Identifier (the object class
is Identification Scheme). this is not only consistent with other components
in Identifier Type but also parallels the way agency details were defined
for Code Types (cf. Code List). However, in table 8-2, we seem to have the
alternative. Here we find Identification Scheme Agency. Identifier and Identification
Scheme Agency. Name .Text. These imply that the object class should be Identification
Scheme Agency. This disagrees with table 8-1 and more significantly does
not follow the pattern for the Code Type and Code List. I made the assumption
that the way Code Type and Code List were constructed was the intended approach
for Identifier and Identification Scheme as well.
Thanks,
Mark
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.
--
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]