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] | [Elist Home]


Subject: Re: [regrep] BIEs re-visited.


David:

All of this is in the latest CC Spec (v 1.80) and also in the
Architecture spec.

What we really could use from CCR is the format for CC realization (in
XML) that works for BIE's as well.  This is probably a good topic for
Tuesdays Joint Coordination Meeting next week.

Duane

David RR Webber - XMLGlobal wrote:
> 
> Joel,
> 
> Good question!  Now I feel like the weather man!!   Maybe I should
> have waited until after the document from Barcelona was available.
> 
> I too am now confused - just when I thought I had this down.   What
> Duane is describing does seem to be a different animal, and
> the complicated behaviour I'm not sure on - seems like we
> would like something simpler - not being a fan of complexity!
> 
> Arrows and boxes on UML diagrams can take some unravelling!
> I'd been shown a totally different one to the one Duane posted!!
> Here's some further notes in hope of flushing out the meaning.
> 
> The CCR team had create a default mapping to XML to store CC's,
> and had realized there are logical CC's (like the ones in the
> already published spreadsheet/doc table) - and physical CC's
> that are associated with those that capture the business context -
> and manifest themselves in existing libraries today (OAG BODS, EDI, etc).
> 
> Seems to me that these physical instances of logical ones are
> very close to being BIEs.   The CCR team had been relying simply
> on the Association mechanism to provide linkage between the
> logical and physical - and then all the behaviours that Duane
> was mentioning fall out of the hat very neatly.
> Even cross Registry association.   However there is
> no way for a Core Component in one Registry to know who has
> linked to it somewhere else out in cyberspace.   That would be
> unenforceable in anycase.  To fix that - one could ask that
> people who do links - register with that master registry and
> tell it the location of theirs.   At least then that Registry could do
> an extended query into those remote registries to see if
> any associations pointed at its content.   But this could only
> be a courtesy mechanism - not mandatory.
> 
> Back to what I posted:  seems like what I described was actually
> aggregated BIEs.   There may or may not be a one to one
> correspondence between aggregated CC's and aggregated BIEs.
> 
> So - looks like we need both - just we need to understand the
> relation.
> 
> Thanks, DW.
> ===========================================================
> Message text written by "Munter, Joel D"
> >
> Now I am a little confused.  It may be just semantics but Duane just stated
> that a BIE is a child of a Core Component and, in the origin of this
> thread,
> David said that a BIE is a re-usable collection of core components with
> optionally associated passive context.  Which is it?
> Joel
> 
> -----Original Message-----
> From: Duane Nickull [mailto:duane@xmlglobal.com]
> Sent: Friday, May 17, 2002 9:41 AM
> To: David RR Webber - XMLGlobal
> Cc: Lisa Carnahan; OASIS Registry List
> Subject: Re: [regrep] BIEs re-visited.
> 
> I am glad that you all are talking about this topic.
> 
> 1. One thing that would be nice for Design Time is for a Business
> Collaboration Designer (new title??) to be able to query the Registry
> for a list of BIE's that are children of a single Core Component AND are
> subject to a single or set of context rules.  Becuase the list is
> possibly very large,  it may be nice to have an ability to set
> parameters for the query results:
> 
> eg. - return only 10 results at a time and only return the URI of each
> BIE.  Also - what is the sort order????  hmmm????
> 
> 2. This should be a function of the Registry itself via "associations".
> 
> Agreeably,  a BIE should also know what Core Component is its' parent.
> I would argue that this should be in the BIE itself, not only the RIM so
> the BIE still contains that information once it is used outside the
> Registry.
> 
> 3.  In cases where their are several Registries whose content is not
> synced,  how will a user get a list of all BIE's made from a specific
> Core Component?  Can result sets be merged?  There may be an onus on the
> Principle Registry of the Core Component to keep track of all of this
> via its' associations mechanism.
> 
> Just some thoughts (probably to keep some of you up an night  ;-)
> 
> D-
> <

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/


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


Powered by eList eXpress LLC