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


I think perhaps "expressed [in, as, by] Metadata" might be somewhat 
more accurate, but since we don't have a strict interpretation of 
this kind of model, at least not that I know of yet, I'm not sure how 
exacting we can be. I've been attempting to make myself choose an 
ADL, just to have a basis for building a modeling tool or as a 
starting point from which to choose a tool to adopt since UML seems 
to have been deemed inappropriate, so I thought I would ask if the 
group has some suggestions?

I have looked at Stanford's Rapide, though I won't have my own Linux 
system to use it on for a few months, and I am looking at Carnegie 
Mellon's ACME now, which at least has a Java LIbrary, though I'm not 
too clear on how one uses that yet. MetaH looks very 
engineering-bound and systems-specific and much too concrete for our 
purposes, although it looks well adapted for use downstream from the 
RM for the sensor-based work in Emergency Management that I'm 
currently being deluged with for the purpose of accommodating that in 
the Emergency Data Exchange Language being worked on in another TC.

I mentioned that as just another note in the choir serenading our 
work that the AIIM eCMS group's desire to use [a, the, some, our] SOA 
RM, exemplifies.

There are a boatload of other constituencies chomping at the bit 
right now to hang their hats on this rack, but, to me, that just 
makes it more imperative that we get it right the first time. Since I 
know that some of us, besides myself, come from a working background 
in media, it is a well known conundrum, exacerbated greatly by the 
onset of computing in the graphics industry, that there is never 
enough time to do a thing right in the first place, but there is 
always time to correct it later (usually because there is no choice 
at that point).

I may have to pull back from my commitment to this work because it is 
requiring more time than I seem to have at the moment, though I won't 
know that for sure for a few weeks. In the meantime I will do my best 
to keep up, and I will withdraw if needs be since this group appears 
to have no lack of active participants, whether I happen to agree 
with the consensus or not. However, regardless, when a group 
approaches relatively new ground as this one is, I believe it is best 
not to be too pressed. I can't believe I am actually writing this 
since I have been on the other side of this argument during most of 
the time I have spent in standards groups.

Must be time to get fitted for a rocking chair.

Ciao,
Rex


At 11:03 AM +0200 5/19/05, Gregory A. Kohring wrote:
>Yes "realized as" is not the right phrase here. Would you
>support "documented in"?
>
>-- Greg
>
>
>Peter F Brown wrote:
>>  I like this diagram more. I think it's closer to my understanding at least
>>  of wherewe want to go.
>>
>>  My only question is: are the semantics *only* realised as metadata? Or more
>>  precisely: in a Reference Model, are the semantics of the service realised
>>  at all? Surely the metadata "realisation" is part of a reference
>>  architecture not a reference model?
>>
>>  -Peter
>>
>>  -----Original Message-----
>>  From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
>>  Sent: 19 May 2005 09:24
>>  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.
>======================================================================


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


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