RE: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Will some readers perceive this as looking very much like a process
diagram (forget the labels for a second), and hence our message may be
lost?

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de] 
> Sent: Thursday, May 19, 2005 3:24 AM
> To: Francis McCabe
> Cc: SOA-RM; dnickull@adobe.com; mattm@adobe.com
> Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, 
> line 201, Figure 2-1
> 
> Frank,
> 
> If I understand you correctly, then in your view there is 
> little to be gained by distinguishing between syntaxt and 
> semantics at this level.  Hence, the "Service Description" is 
> purely semantics.
> 
> Attached is another diagram which depicts this idea. Is this 
> consistent with your ideas?
> 
> -- Greg
> 
> Francis McCabe wrote:
> > While I like the direction in which this is going, I have a 
> couple of
> > issues:
> > 
> > 1. I do not see semantics as being inside service description. 
> > Semantics is an abstract concept that may be referred to but is not 
> > contained in any description.
> > 2. I am not sure why data model is broken out in the way 
> suggested.  
> > To me, tehe data model is an asepct of the semantics of the service.
> > 3. I do not see a hard and fast distinction between syntax and 
> > semantics. Again, any syntactic constraints are simply part of the 
> > overall semantics.
> > 
> > The *reason* for this is that while it is tempting to equate  
> > semantics with application semantics, that is not, in fact, a good  
> > slope to slip down.
> > 
> > Once you liberate yourself from that misconception, one 
> beings to see 
> > all kinds of possibilities. For example, for an 
> encryption/decryption 
> > service, its entire semantic model consists of messages with  
> > encryption markers etc. etc. Is that syntax? Depends on 
> your point of  
> > view; to my mind it is semantics of a simple service.
> > 
> > 
> > Frank
> > 
> > 
> > On May 13, 2005, at 12:01 AM, Gregory A. Kohring wrote:
> > 
> >> Yes, this looks much better. Attached is a slight variation which 
> >> moves the semantics into the description. At one time, 
> "syntax" was 
> >> also explicitly mentioned as being part of the 
> description. Has that 
> >> been dropped?
> >>
> >> -- Greg
> >>
> >> Duane Nickull wrote:
> >>
> >>> Does something like this make more sense than a stack 
> diagram.   This is
> >>> uses a multi-layered approach to group things and reduce 
> the  number 
> >>> of lines.
> >>>
> >>> Duane
> >>>
> >>> Duane Nickull wrote:
> >>>
> >>>
> >>>> The issue we had with the concept map is we ended up with a 
> >>>> proliferation of arrows for items like "semantics" and 
> security  since
> >>>> they are omni-present.   We tried various other 
> depictions and  finally
> >>>> came to the stack.  I agree that the stack alone is not  
> sufficient 
> >>>> and also lends itself to ambiguity so we agreed to place 
> some text by  it.
> >>>>
> >>>> There are standard conventions for interpreting stack diagrams.  
> >>>> For example - layers in the stack are only able to talk 
> to adjacent 
> >>>> layers.  Layer n can interact with n-1 and n+1, but not n+2.
> >>>>
> >>>> The position of the vertical layers indicate they are 
> relevant to  
> >>>> each horizontal layer they are adjacent to.
> >>>>
> >>>> In stack diagrams, there is no named associations 
> present so it is 
> >>>> ambiguous.
> >>>>
> >>>> Accordingly, one can infer the following from the diagram in 2.1
> >>>>
> >>>> Service descriptions (are associated with) services 
> Policies (are 
> >>>> associated with) service descriptions Contracts (are associated 
> >>>> with) policies data models (are associated with) contracts 
> >>>> semantics (are associated with) service descriptions, policies, 
> >>>> contracts and data models.
> >>>> Services, Service descriptions, policies, contracts and 
> data models 
> >>>> may all be discoverable and their presence and 
> availability known.
> >>>>
> >>>> What I do not like is that it also separates the data model from 
> >>>> the service description and separates the contract from 
> the service 
> >>>> description.
> >>>>
> >>>> It may be better to go with a layered concept map.
> >>>> Duane
> >>>>
> 
> 
> 
> --
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================
>