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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-editors message

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


Subject: Re: [ws-caf-editors] lastest model revision


ok, here's the latest with all changes accepted.

Martin, Eric, what do you guys think?

Martin, does this answer many of the questions you have about the model? Where are the ambiguities in your mind?

Greg

PS. Mark, I just took out the "for the same protocol type", which of course makes things ambiguous. However, I don't agree with the change.  First, I'd like to eliminate ambiguity. Second, I'd like to keep the first pass model as simple as possible. Last, we run the risk of different overlapping protocols creating a weird (unintended?) heirarchy of interdependent relationships, which cannot be a good thing.


Mark Little wrote:
I've added a comment and removed others, but I'm happy with it. However, to 
answer your question below:

  
===== Original Message From Greg Pavlik <greg.pavlik@oracle.com> =====
Mark, I've reviewed your changes and I have done two things: some basic
reordering and I deleted the first paragraph under Why Nesting? The
problem I have is that it shows contexts inside of contexts in a way
that is different from previous email discusssions. So in the interest
of moving forward, I suggest we work on that issue separately without
holding up the model in other respects.

At one point, I thought we were aiming at:
<ctx>
   <protocol>foo+bar</protocol>
   <foo data/>
   <bar data/>
</ctx>

though in the last draft we have
<ctx>
   <context1>
   <context2>
</ctx>

Not saying it's wrong, but I don't know how to interpret that.
    

Just different notation for the same thing:

<context1>==<foo data/>
<context2>==<bar data/>

  
also, to answer your three comments:

1) no, I don't think that the text implies only one ALS per activity. It
just gives an example of two separate activities that overlap.
2) agreed, ALSes are treated as optional.
3) for now, yes, I think we should restrict nesting to matching protocol
types if possible (KISS). Otherwise, we're going to eat alot of cycles
in the short term.
    

See new embedded comment.

Mark.

  

CAF model clarification v7.doc



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