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


The data model is a constraint in the sense that the model constrains  
the forms of data accepted/generated by the service.

There is a very smooth progression from syntactic constraints,  
process constraints, quality of service constraints, security  
constraints, business constraints, legal constraints etc. etc.

Frank

On May 20, 2005, at 3:18 PM, Michael Stiefel wrote:

> How is the data model a constraint?
>
> If everything is constraint, what is being constrained?
>
> Michael
>
> At 05:56 PM 5/20/2005, Francis McCabe wrote:
>
>> I would prefer to see
>> 1. policy, contract linked together -- reflecting the contract=agreed
>> policy idea.
>> 2. data model is one of the constraint types, like policy and  
>> contract
>> 3. we should also mention process model if we are going to call out
>> the data model.
>>
>> Being a total pedantic, policy, agreement, process model, data model
>> together characterize the semantics; however, the metadata/service
>> description is a projection of that semantics (there may be several
>> service descriptions for one service).
>>
>> Frank
>>
>>
>> On May 20, 2005, at 2:44 PM, Duane Nickull wrote:
>>
>>
>>> Michael:
>>>
>>> Thanks - I tried it horizontally and for some weird reason, it
>>> seems to resonate better.
>>>
>>> If we can get Frank's sign off and no one else has any opposition,
>>> maybe we can use this one?
>>>
>>> One other thought - should Data Model be larger?  In the book
>>> Documenting Software Architectures, I seem to recall some
>>> conversation about size mattering (yeah yeah). Accordingly, I
>>> enlarged the data model to give it more presence.  How does this
>>> look?  See attached Core RM6.png
>>>
>>> Duane
>>>
>>> Michael Stiefel wrote:
>>>
>>>
>>>
>>>> Would going from right to left or left to right remove any
>>>> associations of top and bottom as more natural or more fundamental?
>>>>
>>>> Have you ever looked at a globe with the Southern Hemisphere at
>>>> the top? To most of us that live in the Northern Hemisphere it
>>>> looks wrong, but of course, from the point of view of outer space
>>>> either pole of the globe could be on top.
>>>>
>>>> I like the fact that semantics will be explained on the side.
>>>>
>>>> Michael
>>>>
>>>>
>>>> At 02:37 PM 5/20/2005, Duane Nickull wrote:
>>>>
>>>>
>>>>
>>>>> Here is a rendering based on Greg's diagram that accounts for all
>>>>> the comments below.
>>>>>
>>>>> - I placed Metadata as a bracket inside the "service description"
>>>>> box.
>>>>> - Semantics will have to be explained using text accompanying
>>>>> this diagram to state that they are omnipresent.
>>>>> - turned the stack upside down so service is at the bottom.  To
>>>>> me, it seemed more intuitive that the thing that is core is at
>>>>> the bottom and the other items are built out (up??) from it.
>>>>> Comments?
>>>>> - used the UML dependency arrow as the convention between service
>>>>> and service description to denote that a SD should not exist
>>>>> without a service.
>>>>> - redrew the line between metadata and policy / contract to
>>>>> connect with the outer container of "constraints"
>>>>> - removed the words "enables discoverability" from the  
>>>>> association.
>>>>>
>>>>> If we use this, we should probably build an appendix containing
>>>>> clear and concise rules about how to interpret this mind map
>>>>> since it borrows association conventions from UML and mixes them
>>>>> together with other conventions.
>>>>>
>>>>> Comments?
>>>>>
>>>>> Duane
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> <CoreRM6.png>
>>>>
>>
>>
>
>
>



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