Core [1] allows delegated creation dialogs to support receipt of an input representation for the purpose of pre-filling fields in the dialog. This has recently come up in the context of some Automation WG scenarios being discussed as candidates for 3.0.
What's "interesting" is that [1] does not obviously allow a client to determine whether or not a creation dialog supports pre-fill. When multiple Automation providers are available, certain implementations consider support for pre-fill a hard requirement so they need to be able to detect those that do not support pre-fill; ideally, prior to "settling on" a choice of provider and indeed prior to showing a list of candidate providers to a human user. Reading between the lines a bit, my guess at the intent is that a client can detect lack of pre-fill support in the spec as it is today by catching a non-201 status code from the attempt to create the pre-filled form. I.e. it can be done reactively, but not proactively. If that is the case, I'm wondering if we could get a straw poll Wed's meeting to see how Core feels about the option of defining a boolean on dialogs (perhaps only used on creation for now, but in principle it's possible to apply the concept to selection as well) allowing an implementation to assert its support for pre-fill. [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Resource_Creation_in_a_dd Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
