wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsdm] F2F agenda item
- From: "Murray, Bryan P." <bryan.murray@hp.com>
- To: <wsdm@lists.oasis-open.org>
- Date: Tue, 28 Jun 2005 21:12:47 -0700
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.
Bryan
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"?
Regards,
David E Cox
Homayoun Pourheidari
<homayounp@gmail.com>
06/27/2005 04:11 AM
Please respond
to Homayoun Pourheidari |
|
To
| "Murray, Bryan P."
<bryan.murray@hp.com>
|
cc
| wsdm@lists.oasis-open.org
|
Subject
| 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.
Cheers,
H.
--
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]