[oslc-core] Buglet in Core 2.0 - non-exemplary(?) use of Change Request

[John Arwe]

Either formulation works for me.
The only "complication" I see in yours Jim is that it could be read to 
differentiate between "complete" and "incomplete" representations, so we'd 
have to adjust my strawman for explaining incomplete as well.  Netting it 
out:
- entity body is always a resource representation
- resource representation MAY be incomplete
- resource representation [whether complete or not] is a set of triples 
that provide initial values... ala previous strawman

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   James Conallen/Philadelphia/IBM
To:     John Arwe/Poughkeepsie/IBM at IBMUS
Cc:     oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:   01/02/2012 08:00 AM
Subject:        Re: [oslc-core] Buglet in Core 2.0 - non-exemplary(?) use 
of Change       Request


I agree that we should probably remove the specific term "change request". 
 

Not to be too nit picky however, can not the the body of the resource be 
complete as well as incomplete?  Perhaps another straw man proposal:
whose entity body is resource representation, that MAY be arbitrarily 
incomplete  

I added arbitrarily to help explain the incomplete part.



Cheers,

jim conallen
Rational Design Management (DM) Lead Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group






From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     oslc-core at open-services.net
Date:   12/30/2011 03:09 PM
Subject:        [oslc-core] Buglet in Core 2.0 - non-exemplary(?) use of 
Change  Request
Sent by:        oslc-core-bounces at open-services.net



Stumbled across the excerpt below at [1]:  note the phrase "content body 
is a change request resource definition ".  Unless "change request" is 
intended to be a term of art that I don't recognize (if so, just a 
different problem), this could easily be read to mean than an OSLC CM 2.0 
Change Request [2] is the only input allowed to pre-fill the creation 
dialog ... which I'm pretty sure was not the intent.  I don't get much 
more satisfaction thinking of it as a (HTTP) PATCH document, especially in 
this context where POST is explicitly called out. 
I'm guessing that a change like the following is needed, so here's a 
strawman proposal: 
from: whose content body is a change request resource definition     to 
to:   whose entity  body is an incomplete    resource representation to 
We might then be faulted for not defining what an "incomplete" resource 
is, and for failing to say what the relationship is between the incomplete 
resource and the (ultimately) newly created resource is.  I could answer 
that with the following strawman (to be inserted where convenient in 
context): 
The incomplete resource representation provides a template for how to 
pre-fill the creation form.  It is simply a set of triples whose 
predicates and corresponding object values provide initial values for the 
resource being created via the form. 



Prefilling Creation Dialogs 
Service providers MAY support receiving a POST request whose content body 
is a change request resource definition to the Creation Dialog URI to 
retrieve a URI that represents the embedded page to be used. Service 
providers MUST respond with a response status of 201 (Created) with the 
response header Location whose value is the URI to request the newly 
created form. 
[1] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up=#Dialog_Resizing 
then page UP one 
[2] 
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#Resource_ChangeRequest 

Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120111/69bef811/attachment.html>