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] RE : [Fwd: [regrep] New ballot "Vote on cc-Review subteam report" (WAS RE:[regrep] Standards approval process)]


Effectively this is what we have done, more or less, in RepXML application.
We have devolopped a set of functions that use JAXR.
The example that you mention is used several times in the RepXML API.
The methods are "composite methods", as you say.

Regards,
Ivan




-----Message d'origine-----
De : Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Envoyé : mardi 18 janvier 2005 23:49
À : Chiusano Joseph; BEDINI Ivan RD-BIZZ-CAE; regrep@lists.oasis-open.org
Objet : RE: [regrep] RE : [Fwd: [regrep] New ballot "Vote on cc-Review subteam report" (WAS RE:[regrep] Standards approval process)]

Sorry - hit Send too early...

Meant to mention also that this could naturally be followed by an Association query such as (from RS 3.0 draft):

SELECT a.* FROM Association a WHERE sourceObject = ${SOURCE_ID}

But I see your point, which is that "composite" methods specific to Core Components and their associated entities would be best. In light of that, there is no reason that an implementation could not have the "getABIE()" method (and related) that you mention below, which maps to a series of behind-the-scenes "native" ebRS method calls that are required to carry out the mission of that method.

I see this as an implementation issue, not a registry specification issue.

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 

> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Tuesday, January 18, 2005 5:39 PM
> To: BEDINI Ivan RD-BIZZ-CAE; regrep@lists.oasis-open.org
> Subject: RE: [regrep] RE : [Fwd: [regrep] New ballot "Vote on 
> cc-Review subteam report" (WAS RE:[regrep] Standards approval 
> process)]
> 
> <Quote>
> for example a "getABIE()" method, has to retrieve full definition 
> components (ABIE with its BBIE and ASBIE
> properties) in an atomic call.
> </Quote>
> 
> Why not a "getRegistryObject()"* method with one of the parameters 
> signifying ObjectType of "Core Component"?
> 
> *may not be the exact name (sent quickly without opening spec - sorry)
> 
> Kind Regards,
> Joseph Chiusano
> Booz Allen Hamilton
> Strategy and Technology Consultants to the World
>  
> 
> > -----Original Message-----
> > From: BEDINI Ivan RD-BIZZ-CAE [mailto:ivan.bedini@francetelecom.com]
> > Sent: Tuesday, January 18, 2005 12:52 PM
> > To: regrep@lists.oasis-open.org
> > Subject: [regrep] RE : [Fwd: [regrep] New ballot "Vote on cc-Review 
> > subteam report" (WAS RE:[regrep] Standards approval process)]
> > 
> > Thanks Farrukh, we agree to edit the mapping and to submit a draft 
> > ASAP to the TC.
> > 
> > 
> > Only to give an example, please find attached to this mail
> UBL Invoice
> > Structure, which represent a "complete" ABIE.
> > The files are : 
> > - one in EDIFRANCE BS xml format (which isn't 100%
> compliant to CCTS
> > yet...)
> > - the other is the BS schema
> > - the last is the ebRIM format (it is only an example, the inner 
> > assosiactions are not provided in the file)
> > 
> > The ebRIM format shows why I spoke about a dedicated API
> for CC. When
> > I retrieve a generic CC in reality I need to retrieve all
> associated
> > sub-component and that couldn't be done by a simple request
> provided
> > by the QueryManager In fact, for example a "getABIE()" 
> method, has to
> > retrieve full definition components (ABIE with its BBIE and ASBIE
> > properties) in an atomic call.
> > 
> > Rgards,
> > Ivan
> > 
> >  
> > 
> > -----Message d'origine-----
> > De : Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] Envoyé : 
> > lundi 17 janvier 2005 22:16 À : regrep@lists.oasis-open.org Objet : 
> > Re: [Fwd: [regrep] New ballot "Vote on cc-Review subteam
> report" (WAS
> > RE:[regrep] Standards approval process)]
> > 
> > 
> > Resending after fixing the subject per Joe's earlier suggestion.
> > 
> > Sorry I think it was me who replied to the wrong message at the 
> > begining of this thread. Please try and use the subject Joe
> started in
> > response.
> > 
> > Thanks.
> > 
> > BEDINI Ivan RD-BIZZ-CAE wrote:
> > 
> > >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 think Ivan touches on an important point above... That the 
> > fundemental issue is the mapping between two information models:
> > 
> > a) The CCTS Information Model (source model)
> > 
> > b) The ebXML Registry Information Model (target model)
> > 
> > Both models are defined in UML and a mapping between the
> two should be
> > the main focus. Such a mapping should be an abstract
> mapping that is
> > independent of Serialization or Storage formats at least initialy.
> > 
> > This whole debate about which comes first: Serialization format or 
> > Storage format is not the core issue to debate IMHO.
> > 
> > Instead we should be debating on the mapping issues between the two 
> > models (see Iva's examles above) and using the ebXML Registry
> > Tutorial:
> > 
> >     http://ebxmlrr.sourceforge.net/tmp/regrep-tutorial-draft-04.pdf
> > 
> > as a key input when trying solution to mapping problems.
> > 
> > BTW, is any one able to take Editorship of above document
> from me as I
> > have become a bottleneck on that document? Ivan, would you be 
> > interested given that you and your colleagues have been using this 
> > document since its earliest version and have some practical
> experience
> > with its content?
> > 
> > Thanks.
> > 
> > 
> > --
> > Regards,
> > Farrukh
> > 
> > 
> > 
> > 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/regrep/members/le
> > ave_workgroup.php.
> > 
> > 
> 
> 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/regrep/members/le
> ave_workgroup.php.
> 
> 


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