[oslc-core] Client introspection of creation factory pre-fill

[John Arwe]

> For me I would think there would be another way to know if a dialog 
> supports pre-fill: using HEAD/OPTIONS on the dialog URL and determining 
if 
> POST is a supported verb.

This meets the feasibility test, will have to see if the exploiters after 
this believes it scales sufficiently.  They tend to come at it from the 
standpoint of "I have a bunch of automation providers that I could present 
to the user for selection, but I want to filter out from the list those 
that do not support behaviors I require (like pre-fill) before displaying 
that selection list."

Certainly the implementation could deal with this in different ways, like 
displaying the entire list (after whatever of pro-active filtering is 
possible w/o additional network flows) provisionally and showing a 
progress indicator while it asynch'ly does the HEAD/OPTIONS checks.


> For an extension in the future, I could imaging that if there was a 
> resource shape associated with a dialog it would not only describe what 
is 
> allowed for the pre-fill...it could be used to know that pre-fill itself 

> is supported (barring access/auth restrictions)

The predicate(s) would have to be clear.  For a creation dialog, the 
resource shapes you accept for pre-fill might (probably will) differ from 
those you'd produce as a consequence of Create.  Modulo that, seems 
reasonable and definitely supports the kind of pro-active filtering 
scenario above better.  OTOH, creation factories (programmatic ones) 
should have the same bifurcation; the core:CreationFactory resource should 
have the same issue, but I cannot tell reliably from reading the 
oslc:resourceShape  description whether it's describing inputs or outputs.


Best Regards, John

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130612/d551b66d/attachment-0003.html>