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. 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)
Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net > From: John Arwe/Poughkeepsie/IBM@IBMUS > To: [email protected] > Date: 06/10/2013 03:14 PM > Subject: [oslc-core] Client introspection of creation factory pre-fill > Sent by: "Oslc-Core" <[email protected]> > > 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 > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
