Heather, the same interoperability argument applies to wsrf:Selector or
wsn:TopicExpression which both have dialects. By basing on WSRF and
WSN WSDM already inherits the "non-interoperability" you're refering
to. And also many more of other similar standards out there are like this.
You specify standard dialects and let people extend this for their needs.
Managers needs to understand the dialects they care about, not all possible
dialects. That's called extensibility. There is no way we can guess now
what kind of other reference kinds are possible...
-----Original Message----- From: Heather Kreger
[mailto:kreger@us.ibm.com] Sent: Fri 8/13/2004 1:20 AM
To: Sedukhin, Igor S Cc: Vambenepe, William N;
wsdm@lists.oasis-open.org Subject: RE: [wsdm] One more idea on
relationships
I'm getting uneasy that there is going to be gratuitous creation of new
dialects for random reasons. I'm concerned that this will reduce
interoperability. All managers will have to understand all dialects to be
able to interoperate. Developers may not try to use standard dialects that
all managers can understand and only build custom dialects if they
absolutely need them because it is too easy.
We need to make sure
sufficient information is in the base model to do the job and not push
function to extensibility traits if we think it will be a common case to
deal with.
Selfness seems like a common problem, ESPECIALLY with
multiple dialects and resource names. I think its an interesting problem
whose solution is probably not more information in a dialect.
Heather
Kreger STSM, Web Services Lead Architect for SWG Emerging
Technologies Author of "Java and JMX: Building Manageable
Systems" kreger@us.ibm.com 919-543-3211 (t/l 441)
cell:919-496-9572
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
08/12/2004 11:41 PM |
| This is a reference dialect. Just define a new dialect in the spec. No
reason to have an attribute which is always there, but sometimes true
sometimes false. -----Original Message----- From:
Vambenepe, William N [mailto:vbp@hp.com]
Sent: Thu 8/12/2004 9:33 PM To:
wsdm@lists.oasis-open.org Cc: Subject: [wsdm] One more
idea on relationships
Here is a potential problem:
I
have an EPR to a resource foo. I ask resource foo to send me
the "containment" relationships it's involved in. It returns
one relationship to me. This relationship contains an EPR pointing to
the container and an EPR pointing to the containee. The trouble is,
neither of these EPR matches the EPR I used to contact foo. Since there
could be more than one EPR per resource, this is perfectly possible. How do
I know whether foo is the container or the containee?
Retrieving the
ResourceId may help, but even this is not guaranteed to succeed. And it
might require more round trips.
I suggest that we create an optional
"self" attribute of type boolean that can be placed on a participant in a
relationship. By placing it on a participant, a resource that sends the
relationship indicates that it is the participant in question. Obviously,
if the relationship is retrieved from someone who is not a participant in
the relationship, the "self" attribute would not
appear.
Regards,
William
To unsubscribe from this mailing
list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.
|