> 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
