[OSLC] OSLC QM 1.0 specification

[Arthur Ryman]

Martin,

The estimation spec has evolved somewhat  from the example below, but is 
still consistent with this use of multi-valued properties to define 
collections. We are taking an even simpler approach to collections:

for every resource type, e.g. Estimate, we have a singleton collection 
resource, e.g. EstimateList
to create a new resource, you POST to its List resource
the List resource has a multi-valued property that defines its members, 
e.g. EstimateList has a multi-valued ems:estimate property that refers to 
Estimate resources
in this example, the Estimate resource also has a property, ems:project, 
that refers to its owning Project
to get the collection of Estimates for a given Project, you GET the 
EstimateList resource with a query parameter that filters the collection

This design has the feature that the scope of a Project resource does not 
include the Estimates that refer to it, i.e. when a new Estimate is 
created, it does not update the Project. If you wanted to regard the 
Estimates as being part of the Project, then you would add explicit 
ems:hasEstimate properties to the Project.

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 



Martin Nally/Raleigh/IBM at IBMUS
12/09/2009 03:06 PM

To
Paul McMahan/Raleigh/IBM at IBMUS, Arthur Ryman/Toronto/IBM at IBMCA
cc
community at open-services.net, community-bounces at open-services.net, 
oslc-qm at open-services.net
Subject
Re: [OSLC] OSLC QM 1.0 specification





This design adopts the design for multi-valued properties documented in 
the CM spec. I don't think this is a good design and we shouldn't 
propagate it. The OSLC estimation workgroup is doing this the "right" way, 
as shown in this example:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:ems="http://open-services.net/software-metrics/">
   <ems:Project
      rdf:about="http://braintwistors.example.com/ems/v1.0/Project/4201">
      <dc:title>Tsunami 1.0</dc:title>
      <dc:description>
         The goal of ... 
      </dc:description>
      ...
      <ems:hasEstimate
         rdf:resource="
http://braintwistors.example.com/ems/v1.0/Estmate/4203" />
      <ems:hasEstimate
         rdf:resource="
http://braintwistors.example.com/ems/v1.0/Estmate/4204" />
      ...
      <!-- other properties of this project resource have been omitted for 
brevity -->
   </ems:Project>
</rdf:RDF>

In other words, a multi-valued property is just what it says - a property 
with multiple values, as illustrated here by "ems:hasEstimate". You do not 
introduce a separate collection resource with separate link resources - 
that design is not in the spirit of REST, it's just an old-fashioned OO 
programming API exposed via http.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: (949)544-4691




From:
Paul McMahan/Raleigh/IBM at IBMUS
To:
community at open-services.net
Cc:
oslc-qm at open-services.net
Date:
12/09/2009 12:05 PM
Subject:
[OSLC] OSLC QM 1.0 specification
Sent by:
community-bounces at open-services.net




The OSLC Quality Management V1 specification is available at :
http://open-services.net/bin/view/Main/QmSpecificationV1

I would like to thank the Quality Management workgroup members (BigLever,
IBM, Sogeti, and Tieto) for their participation in the workgroup and
contributions to the specification.  The broader OSLC community is invited
to view the specification and provide any feedback in the wiki or via the
oslc-qm at open-services.net mailing list.  The Quality Management V2
specification effort is expected to get underway soon so any feedback on
the V1 specification will be especially valuable.


Best wishes.
Paul McMahan
Rational Quality Management
pmcmahan at us.ibm.com


_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20091210/dea4c223/attachment-0003.html>