Re: [ubl-lcsc] Modeling Core Component Types

[Tim Benson <tim.benson@abies.co.uk>]

This model is helpful. On initial review, I would have wished to see much
less optionality.  Only about three of the links are mandatory - the rest
are all optional.  I am greatly in favour of making as many links as
possible mandatory, and removing any which are seldom if ever likely to be
used.  Optionality is (or should be) a four letter word, to be avoided
except under provocation :-).

Tim Benson

On 12/2/04 7:01 am, "Tim McGrath" wrote:

> 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.
> 
> Over the past few weeks we had had various discussions about how to deal
> with this in a more controlled manner.
> 
> One of the options is to go back to our basic design approach and create
> models of these from which XSD code can be generated.  I know the
> Michael Dill has been keen to see this.
> 
> 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 would be interested in other opinions on this strategy - particularly
> Michael and the TBG17 group.
> 
> PS this exercise exposed a few typos (i suspect) in the specification so
> few objects have slightly different names.

-- 
Tim Benson
Abies Ltd, 7 White Court, Platts Lane, London NW3 7PL, UK
tel +44 (0)20 7431 6428, fax +44 (0)20 7794 2078, mob +44 (0)78 5568 2037