[oslc-core] awkward statement in Core on pre-filling creation dialogs

[Steve K Speicher]

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 09/01/2011 04:32 PM
> Subject: [oslc-core] awkward statement in Core on pre-filling creation 
dialogs
> Sent by: oslc-core-bounces at open-services.net
> 
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;table=up;up=#Dialog_Resizing then page up 
> 
> 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. Service 
providers MAY NOT
> maintain the created form in a persistent storage. Clients SHOULD expect 

> that after some elapsed time, a GET on these transient response URIs MAY 

> result with response status codes of 404 (Not found) or a 3xx 
(Redirect). 
> "MAY NOT" could be read to mean "MUST NOT" or "MAY" ... if the intent 
was to
> allow implementations to do whatever they want, dropping NOT reads no 
worse 
> and conveys the intent clearly.  Assuming that same intent, if the 
purpose 
> of using MAY NOT in the original was to gently nudge readers towards 
> thinking "bad idea, why would I do that", then SHOULD NOT or NOT 
RECOMMENDED
> might be more appropriate. 

I think this may have been a case of RFC-2119 upcasing.  I think the 
intent of that original statement is informative in saying that servers 
may (or may not) persist something on the server.  Just because you 
receive a POST request, it is possible to respond with a new URL in the 
Location header with a 201 response.  I might recommend that the upcasing 
and choice of words be reconsidered.  Such as "Service providers MAY 
maintain the created form in a persistent storage." but does that really 
make it any better.  Other suggestions welcome

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645