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: Re: [wsdm] F2F agenda item

It looks like we have a variety of opinions on this topic - which is exactly why we need to talk about it!
Zulah brings up some good questions we should answer about capabilities before making any decisions about how to represent them.
I just want to point out that the WSDM specs currently define a capability by using WSDL and schema to create a portType, thus equating a capability to a portType (or interface) - this is option #1. Thus defined I believe it is difficult to define the same property in more than one capability. In the end, the interface aggregation mechanism used by WSRF will result in a single occurrence of any property QName in the final portType.
XML schema does discuss a means of "extending" a complexType, however, WSDL does not provide any means to "extend" a portType. Without a clear definition of how to extend a capability, it is not meaningful to discuss "extending" a capability. It is not sufficient just to say that a capability is extensible - you must explain how to do this. Reading the XML schema, WSDL, and WSDM specs do not provide enough information about how to extend a capability.
There are advantages to both definitions of capability. As David points out with #1 you know exactly what properties and operations the resource supports if you know it supports a capability (determining whether it supports the capability is another matter). And as Homayoun points out #2 offers more flexibility in terms of having properties belong to more than one capability and in adding properties to a capability later or even from a different namespace.
I think we need to discuss what we want from capabilities (Zulah's questions might help), and then see how the 2 ways of representing them address what we want.

From: David E Cox [mailto:decox@us.ibm.com]
Sent: Monday, June 27, 2005 5:58 PM
To: Homayoun Pourheidari
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] F2F agenda item

Hi Homayoun,

  The way I read #1, the specific combination or set of properties, operations, and notifications would be a capability and would presumably have a name.  I think that the individual properties, operations, and notifications can certainly be used in other combinations to create different capabilities with different names.

  So, I don't think #1 means that capabilities have to be mutually exclusive.  I also don't think #1 prevents one from combining capabilities into "composite" capabilities or from "extending" a capability by adding new properties/operations/notifications to create a more specific capability.

  I personally like #1; I think it gives some structure to the whole mess!  When you refer to a capability by name, you know what is in it.  We can still create the concept of categorization described in #2, but it should be called something other than "capability".  How about "capability category"?
David E Cox

Homayoun Pourheidari <homayounp@gmail.com>

06/27/2005 04:11 AM
Please respond to
Homayoun Pourheidari

"Murray, Bryan P." <bryan.murray@hp.com>
Re: [wsdm] F2F agenda item

+1 for the second choice.

As I recall, there were many use cases where a property or an
operation can belong to different management capabilities that one may
define.  Of course, you can go out of your way to define "capability"
categories that are mutually exclusive.  But I believe that is not how
most people would relate to manageability information.

A wsdm capability should be considered a meta data that can be
attached to various components of manageability information to form a
category that provides a meaningful manageability semantic.


On 6/25/05, Murray, Bryan P. <bryan.murray@hp.com> wrote:
> I had an internal discussion about WSDM capabilities today that makes me
> wonder if all of the WSDM TC understand capabilities in the same way.
> Heather could you add an agenda item to talk briefly about capabilities
> during the f2f.
> As a teaser, the 2 ways of looking at capabilities are:
> 1) A capability is a set of properties, operations, and notifications
> described by WSDL/schema. Once defined, the capability has a fixed set
> of properties, operations, and notifications - it is like a portType,
> forever constant.
> 2) A capability is a means of categorization. Capabilities are defined
> independent of properties, operations, notifications. Any property,
> operation, notification can be assigned to zero or more capabilities to
> show that they have something to do with that category of functionality.
> A capability has nothing to do with a portType and new properties can
> claim they are associated with an existing capability.
> Bryan
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

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