RE: Feedback on Glossary

Assaf,

See below.

Fred

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Tuesday, April 22, 2003 10:19 PM
> To: Cummins, Fred A
> Cc: Monica J. Martin; public-ws-chor@w3.org
> Subject: Re: Feedback on Glossary
> 
> 
> Cummins, Fred A wrote:
> 
> >Monica,
> >
> >Process.  A process is a group of interrelated actions or 
> activities that
> >are specified to achieve a defined objective and are 
> complete when that
> >objective is achieved or abandoned.
> >  
> >
> I picked this interesting definition from, or all places, pi-calculus:
> 
> A process is generally nothing more than a set of commitments.

[fac] This seems a bit too simplistic.  One could infer that a process
does'nt actually accomplish anything.
> 
> >Process instance. The execution of a process to achieve its defined
> >objective in a particular situation.
> >  
> >
> +1
> 
> >Role. An abstract designation for a participant in a 
> choreography that is
> >bound to a particular participant URI when the choreography 
> is performed.
> >In some choreographies, the same participant may be bound to 
> multiple roles,
> >or a role may be bound to different participants at 
> different times during
> >the execution of a choreography.
> >  
> >
> +1
> 
> >State.  An attribute value or set of values of attributes of 
> an entity that
> >represent a condition of interest for that entity.  
> Typically, a number of
> >states of an entity are of interest, each will be named, and 
> the events
> >which may cause transitions between these states will be 
> defined for state
> >transitions.  The alternative states of an entity will 
> typically be defined
> >in a particular context (an entity may have many states of 
> interest in
> >different contexts), and suggests--by reference to state 
> transitions--how
> >that entity will behave in the associated context.
> >  
> >
> +1 with a minor objection.
> 
> Some state transitions are better defined as graphs depicting the 
> possible transitions between a finite set of states. For example from 
> submitted to approved to pending to shipped. Other state 
> transitions are 
> not easily modeled as graphs like that. For example, if I 
> have a price 
> for the order and I need to add shipping & handling based on the 
> destination and weight, the transition is from some number N to some 
> other number N. Do I write a graph with all possible state 
> transition s 
> or are there some transitions not modeled as a graph? Can we identify 
> more generically these two types of states and transitions?

[fac] I wonder if we couldn't leave this discussion to the definition
of state transition.
> 
> >Service type.  A service that conforms to a WSDL interface 
> and conforms to a
> >defined choreography in a specified role.
> >  
> >
> WSDL interface defines some of the expected behavior of a 
> service type 
> and WS-Chor defines other part of that behavior. WSDL can 
> also define an 
> interface beloning to that type by associating it with the interface. 
> However, somewhere along the actual concept of service type 
> managed to 
> escape and I think we need to introduce it in more generic terms than 
> the particular type of WSDL definition used to capture its behavior.

[fac] Is your intent to attach some additional semantics to a service
type?  If not, what will distinguish one service type from another if not
the WSDL and choreography?
> 
> arkin
> 
> >Fred Cummins
> >EDS
> >
> >  
> >
> >>-----Original Message-----
> >>From: Monica J. Martin [mailto:monica.martin@sun.com]
> >>Sent: Tuesday, April 22, 2003 1:05 AM
> >>To: Steve Ross-Talbot
> >>Cc: public-ws-chor@w3.org
> >>Subject: WS[Chor 4/21/2003: Updated Cases Submitted and Choreography
> >>Terms to Consider
> >>
> >>
> >>As indicated, attached is the working glossary with the comments I 
> >>received from Assaf and Hugo. I also heard from Mike Brumbelow, who 
> >>wishes to assist on glossary. Mike, please do a pass over this for 
> >>tomorrow and once the discussion gets going, we'll do so as 
> >>well. Those 
> >>items in red in the document are changes made from comments 
> received. 
> >>Comments / questions are also inserted in these sections, for team 
> >>discussion at the appropriate time.
> >>
> >>As well, as requested last week, I've added additional detail 
> >>to my two 
> >>cases for consideration with some potential areas to mine for 
> >>requirements. These scenarios were based on real world 
> >>requirements in 
> >>European and high technology/electronic component industries.
> >>
> >>Thanks.
> >>Monica J. Martin
> >>Sun Microsystems
> >>
> >>
> >>Monica J. Martin wrote:
> >>
> >>    
> >>
> >>>I have the glossary with questions for the group to address 
> >>>      
> >>>
> >>and will 
> >>    
> >>
> >>>distribute this afternoon (MT).
> >>>Thanks.
> >>>Steve Ross-Talbot wrote:
> >>>
> >>>      
> >>>
> >>>>Any suggestions?
> >>>>
> >>>>I have until 8:00pm my time (UK) to firm this up and get it out.
> >>>>Cheers
> >>>>
> >>>>Steve T
> >>>>
> >>>>This email is confidential and may be protected by legal 
> >>>>        
> >>>>
> >>privilege. 
> >>    
> >>
> >>>>If you are not the intended recipient, please do not copy 
> >>>>        
> >>>>
> >>or disclose 
> >>    
> >>
> >>>>its content but delete the email and contact the sender 
> >>>>        
> >>>>
> >>immediately. 
> >>    
> >>
> >>>>Whilst we run antivirus software on all internet emails 
> we are not 
> >>>>liable for any loss or damage. The recipient is advised to 
> >>>>        
> >>>>
> >>run their 
> >>    
> >>
> >>>>own antivirus software.
> >>>>
> >>>>        
> >>>>
> >>>
> >>>      
> >>>
> >>
> >>    
> >>
> 
> 
> -- 
> "Those who can, do; those who can't, make screenshots"
> 
> ----------------------------------------------------------------------
> Assaf Arkin                                          arkin@intalio.com
> Intalio Inc.                                           www.intalio.com
> The Business Process Management Company                 (650) 577 4700
> 
> 
> This message is intended only for the use of the Addressee and
> may contain information that is PRIVILEGED and CONFIDENTIAL.
> If you are not the intended recipient, dissemination of this
> communication is prohibited. If you have received this communication
> in error, please erase all copies of the message and its attachments
> and notify us immediately.
> 
>

Received on Tuesday, 22 April 2003 22:45:41 UTC