[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]