OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] Standards approval process


I'm sorry but the mapping is not so simple:
the better solution for ASCC and ASBIE is an ebRIM association or an
extrinsic object ?
do we need a dedicated registry object for BCC, BBIE, ASCC, ASBIE
properties or an association is enough?
Business Context will be a registry classification or an extrinsic
object ?
................................................

................................................

I understand why you tell that the serialization is most important that
how we will store that, belive me. but we forgot the CCTS UML schema. 
My feel is that the serialization of the CCTS is not so simple. 

So we can :

1 - give an XML format that answer to all needs or

2 - assure that we are able to treat the submitted information


in this case if we arrive to define how all the classes are mapped into
ebRIM, than we will be able to map every serialization that we provide
to CCTS. 

I think that for CCTS the better approach isn't :
"If someone sends me a core component, what will I get?"

but :
if someone sends me a core component (in XMI, XSD,TBG Excel, OASIS ebXML
Registry SCM SC serialization, LomakeFi format, EDIFRANCE BS, ...), am I
sure that I will be able to store all information and retrieve that?
After we can speak about what serialization is better ...

are you agree ?


regards,
Ivan 



Le lundi 17 janvier 2005 à 12:08 -0800, Duane Nickull a écrit :
> Ivan:
> 
> Please understand that I do not have all the answers, although I think I 
> did answer many of them, it raised a lot of questions around scalability.
> 
> Answers inline:
> 
> BEDINI Ivan RD-BIZZ-CAE wrote:
> 
> >Please Duane, give us your mapping and if it will well formed we will
> >stop this discussion immediately :-P
> >  
> >
> The mapping is simple.  You store a [CC || ACC || BIE || ABIE] as a 
> registry object. When you need it, you get it from the registry as a 
> whole object.  Doing this also solves a second problem of a 
> serialization format for interchange of CC's, BIUE's etc.  That is why I 
> favour this.  It is also cleanly decoupled from any dependency upon a 
> registry.
> 
> I have given an example of storing a BIE inline within a CC under the 
> /representations element.  There can be multiple representation elements 
> present given that there will be multiple BIE's for a CC, each used 
> within a different set of contexts.  The context set is a keyed value 
> than allows the correct BIE to be identified by the modeller based on 
> his or her contexts.
> 
> The inline method will not scale well if there are lots of BIE's 
> therefore, I would make a reference to the BIE and context and store 
> them as separate registry objects.
> 
> Aggregates are expressed as a aggregated relationship for CC's (Not sure 
> why composites are not used here but that is for CEFACT to decide.)
> 
> >sincerely give us the possibility to have a little doubt about how you
> >deal CC in your mapping. in the solution that you provide we can't
> >distinguish a BBIE from an ACC. all is CC for you.
> >  
> >
> Not true.  It is very complicated but I used the same schema to define 
> the metadata for all objects.  The differentiator is in the enumerated 
> lists.
> 
> example
> 
> <Object type="[BIE || ABIE || CC | ACC]" /> allows you to declare what 
> the thing is.
> 
> The properties map all the CC properties properly.
> 
> <Property name="foo" value="bar" />
> 
> >  
> >
> >>DN - that is what RSS is for.  We should not define a separate API just 
> >>for CC related things.
> >>
> >>    
> >>
> >
> >Why not ?!?
> >  
> >
> The simple answer is that it is generally a bad practice to add features 
> that are redundant with existing features without a compelling reason.  
> I see no compelling reason why we should develop a new API when the one 
> we have works perfectly for the purposes discussed.
> 
> >>DN -registry federation can do this.  We do not need to make another 
> >>spec to do this.
> >>
> >>    
> >>
> >
> >Please share your experience with us.
> >  
> >
> DN - read the federation feature of the registry spec - it explains all.
> 
> Duane
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]