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.


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-
<


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


Powered by eList eXpress LLC