RE: [provision] Groups - 2.0-Relationships.pdf uploaded

["Cohen, Doron" <Doron_Cohen@bmc.com>]

Gary,

As you kindly reminded the list, the requirement we had for SPML was the
ability to represent relationships in native SPML . When you translate that
to use cases and model environments this leads us to the need to be able to
represent attributes of the relationship. Otherwise the model is too limited
to address use cases that our customers look for. The fact that we did not
spell this out at the high level requirement list, does not mean whatsoever
that this is not a functional requirement from the solution we put.

As long as we can maintain the model simple (which is what I believe to be
the approach I suggest) I am for including it .

Doron



-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Thursday, July 22, 2004 6:16 PM
To: Cohen, Doron
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Groups - 2.0-Relationships.pdf uploaded


Cohen, Doron wrote:

>Gary,
>
>A significant functional requirement for SPML 2.0 is the ability to 
>express attributes/properties for connection/relationships .
>
Doron,

I didn't recall that being a requirement, so I went back to look for it 
in   
http://www.oasis-open.org/apps/org/workgroup/provision/download.php/5011/dra
ft-pstc2-requirements-04.doc
The following requirement is the only one I saw that deals with 
relationships. 

> SPML V2 must allow for the representatation of relationships between
> provisioned objects for request and response data elements. This needs 
> to work for the data as part of the request/response and also part of 
> any operational attributes. 

Do you read this as requiring that relationships have attributes?  I had 
understood it simply to mean that one needed to be able to manage the 
set of relationships for an object, and that the set of relationships 
for an object should be represented as data associated with the object.

I am not opposed to adding support for complex relationships, but I see 
this as a *goal* and not as a requirement.  If we can support complex 
relationships without (overly) complicating simple relationships, then 
we should.   Otherwise, I believe that explaining how to model complex 
relationships using SPML 2.0 must suffice. 

The perfect is the enemy of the good.

Gary