Re: [ubl-lcsc] Modeling Core Component Types

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

you are correct that the UMM is not tool driven.  in fact, the reality 
is worse, there is a believe that using UML as a modeling language means 
compliance with UMM!

but surely the point is that it is the artifacts that count.  The fact i 
use UMM to define a business process and express this is some form of 
schema and you use UMM  to define a business process and express this is 
some form of schema does not mean we will have any interoperability. 
 conversely, i could develop a schema on the back of a cigarette box and 
it be interoperable with a UMM developed one.

the obvious answer for any methodology is keep it simple, demonstrate it 
works and make it easier to do than anything else.  in other words, they 
are adopted by survival of the most practical.

BTW the UMM has nothing to say about information modeling - so it does 
not really have any bearing on this debate.  

what we are modeling are the structures defined by the CCTS for 
representing data types.  I am not sure we want to buy into a design 
task - just an analysis one. Having said that i personally dont see any 
conceptual modeling difference between an ABIE and a BBIE and CC Type 
and its supplementary components.  They are both aggregations.  We could 
simply apply UBL NDR rules to them as per BIEs.  This is clear when we 
see how the UBL Names come out in the models.  Such generated UBL CCT 
schemas would still be CCTS compliant - because that spec does not care 
how the implementation schemas look.

however from an ownership perspective, the CCTS structures belong to 
CEFACT and we would like to use their implementations of these once it 
stabilizes (presumably within the ATG2 group).  


Anthony B. Coates wrote:

> On Sat, 14 Feb 2004 19:14:47 -0500, CRAWFORD, Mark <MCRAWFORD@lmi.org> 
> wrote:
>
>> Exactly what the UN/CEFACT Modelling Methodology (UMM) is all about.  
>> A defined methodology for using UMM to define business processes.
>
>
> OK, good, but do the UML tools give you any support for imposing the 
> methodology?  I suspect not.  I suspect you could implement an 
> equivalent modelling strategy using data models written in XML rather 
> than UML, and then use XML schemas of various flavours to help impose 
> the methodology.  So what I am getting at is not "is there a 
> methodology", but "how do you help contributors avoid accidentally 
> doing things that are outside of the methodology".  There fewer ways 
> there are for people to do things wrongly, the more they can spend 
> their energies on the real business of putting together the required 
> models.
>
>     Cheers,
>         Tony.
>

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