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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


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


Title: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1
Well actually, the overall organization of the figure (more than just the arrows). I like your suggestion of removing the arrowheads - that may solve it.
 
Joe


From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
Sent: Thu 5/19/2005 7:18 AM
To: Chiusano Joseph
Cc: SOA-RM
Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1

You mean because of the arrows?  Would it help if we removed
the arrow heads?

-- Greg

Chiusano Joseph wrote:
> 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.
>>======================================================================
>>
>
>


--
======================================================================
G.A. Kohring
C&C Research Laboratories, NEC Europe Ltd.
======================================================================



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