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

["Gregory A. Kohring" <kohring@ccrl-nece.de>]

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