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




BEDINI Ivan RD-BIZZ-CAE wrote:

>I'm sorry but the mapping is not so simple:
>  
>
DN - you are right - very complex.

>the better solution for ASCC and ASBIE is an ebRIM association or an
>extrinsic object ?
>  
>
Could be.  I would assert that nobody knows the requirements since 
nobody knows how big it may eventually scale.

>do we need a dedicated registry object for BCC, BBIE, ASCC, ASBIE
>properties or an association is enough?
>  
>
All tghose things CAN be registry objects.  It is one way of doing 
things and it does have it's merits (simplification, no dependency upon 
registry).  The associations within the registry can represent the 
relationships between the things.

>Business Context will be a registry classification or an extrinsic
>object ?
>  
>
Actually, I think that the context declaration is an intrinsic object 
and it is the least understood of all the mechanisms in CCTS. A 
"context" is made up of 8 (current specifications) separate contexts. 
There are no enumerated lists of values for each single context 
therefore there is no way to guarantee interoperability.  It is also 
possible that contexts may have ranges, multiple applicable values and 
also may need to be subdivided smaller.  The result is approximately 35 
million different context possibilities.  The magnitude of this problem 
and lack of clarity scare me.

>................................................
>
>................................................
>
>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. 
>  
>
DN - the first thing to do was to define the requirements for 
serialization.  We did that and it was approved by this TC.

>So we can :
>
>1 - give an XML format that answer to all needs or
>  
>
DN - IT is a good short term fix but as I said earlier, it does have its 
issues.

>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 ?
>  
>
Not here.  Before you can store it, you have to be able to read it.  
Therefore, you have to know the serialization format.

;-)

Duane

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Chair - OASIS eb SOA TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
***********



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