Simplifying our models

Our models capture quite a lot of detail.  Indeed, I'm concerned that they 
model too many concepts and appear overly complex.  I believe our document 
will have greater impact if we present something simpler.

To this goal, I'd like to propose that we either de-emphasize, consolidate 
or remove some of the concepts from our model diagrams, while still 
retaining the ideas in the explanatory text.  (I'm not sure whether the 
ideas should also be retained as full-fledged concept definitions or merely 
included in explanatory text.)

On today's editors' call, we brainstormed on some ways that we might 
simplify the model diagrams:

1. Remove concepts from the diagram that seem less central than others (but 
retain the ideas in the explanatory text).

2. Visually highlight certain concepts that we deem the most central, thus 
de-emphasizing the others.

I'd like to hear other peoples thoughts on this.  Are the model diagrams 
too complex?  Should we remove or de-emphasize some of the concepts in 
them?  If so, which ones?

As a starting point, I will suggest the following.

MESSAGE ORIENTED MODEL
Remove/de-emphasize message correlation
Remove/de-emphasize delivery policy
Remove/de-emphasize message reliability

SERVICE ORIENTED MODEL
Remove/de-emphasize Goal State
Remove/de-emphasize Action
Remove/de-emphasize property
Remove/de-emphasize choreography (or change to MEP?)

RESOURCE ORIENTED MODEL
(No changes suggested)

POLICY MODEL
Remove/de-emphasize Denial
Remove/de-emphasize Controlled resource
Remove/de-emphasize Permission guard
Remove/de-emphasize permission
Remove/de-emphasize Obligation
Remove/de-emphasize Audit guard
Remove/de-emphasize Remedy
Remove/de-emphasize constraint
Remove/de-emphasize Policy description
Remove/de-emphasize domain
I.e., reduce to:
         person or organization
         agent
         policy
         action

MANAGEMENT MODEL
I actually think we can omit this model and rely instead on the stakeholder 
section on Management, because there isn't anything in our WS architecture 
that is uniquely intended for management.  I.e., WS management is achieved 
by *applying* the WS architecture to the requirements for management.

I am not married to the above suggestions.  I'm just throwing them out as 
possibilities.

Also, I am NOT suggesting that we use the mailing list to try to *decide* 
which concepts to remove or de-emphasize.  At this point, I think it is 
best to defer to the editors' judgement quite a lot on this, because we 
need to have a coherent set of concepts represented.  Rather, my intent 
here is to gain input for the editors about what people think we should try 
to do in order to achieve a document with the greatest impact.


-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Wednesday, 14 January 2004 17:39:20 UTC