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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

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


Subject: Proposal to resolve SituationType disagreement



Hi all,

I tried to come up with a proposal that would hopefully allow us to come
to an agreement on "SituationType". Here is the proposal below. I ran it
informally by some members of the group and it seems to work well. I'd
like to discuss this on the call today.

Regards,

William

<proposal>

Do with MUWS what schema, WSDL, SOAP etc do: break it in parts.

Part 0: Primer

Part 1: MUWS core
  - intro
  - terminology
  - architecture
  - support from web services platform (partial)
  - identity capability
  - manageability characteristics (capabilities)
  - correlatable properties
  - very limited WEF (without situation, priority and severity but with
extensibility to add them, which is what part 2 does)
  - defining a manageability interface

Part 2: MUWS
  - support from web services platform (the rest of it)
  - state / status
  - metrics
  - configuration
  - relationships / relationship access / relationship resource
  - the rest of WEF (situation, including the top-level list of
situationTypes, priority and severity)
  - advertisement
  - more discovery

This doesn't change the total scope of what is in MUWS. I am not talking
about adding/removing stuff.

This works really well. Look at WSDL 2.0. People who want to work on it
at the interface level (for example standards that define well-known
interfaces) only need to use part 1. People who want to use it to send
real messages around (interoperability) need part 1 and part 2.

This is not a major editing work more like moving stuff around. Part 0
(primer) can come a bit later, as currently planned.

</proposal>



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