Jim, A creation factory has a link to a shape (oslc:shape) resource that descibes that resources it creates, e.g. blog entry versus blog comment. Isn't that enough to identify the purpose of the creation factory?
Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Jim des Rivieres/Ottawa/IBM@IBMCA To: Scott Bosworth <[email protected]>, David M Johnson <[email protected]>, Steve K Speicher <[email protected]> Cc: [email protected], John Wiegand <[email protected]> Date: 05/31/2010 09:57 AM Subject: [oslc-core] programmatic selection of creation factories Sent by: [email protected] ref: http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT (r95, May 27) Architecturally, it makes sense for a particular Service to have multiple occurrences of creationFactory. Take the example OSLC Blog Service as a concrete instance: Blog Entry and Blog Comment each have a creationFactory. The CreationFactory inline local resource carries a mandatory dc:title that helps a user in choosing among them. However, I don't see anything that would allow a programmatic client to make an analogous choice. For instance, if my client needs to create a Blog Entry, how would it discover which creationFactory to use? In general, OSLC domains must support the needs of programmatic clients as well as ui clients. Adding a mandatory identifier to CreationFactory would do the trick. The identifier could be a URI. Well-known URIs could be defined in the OSLC domain spec; i.e., OSLC Blog Service could declare the identifiers "http://open-services.net/bogus/blog/createEntry"; and " http://open-services.net/bogus/blog/createComment"; for distinguishing its primary creation factories. All clients would be told to tolerate and ignore entries with identifiers that they do not recognize; this allows new identifiers can be introduced at any time without affecting programmatic clients. And the mechanism can be opened up to individual providers by allowing a provider to define additional provider-specific identifiers. I would make the exact same argument for queryCapability, selectionDialog, and creationDialog as for creationFactory. Any OSLC domain that has multiple major resource types might decide to provide separate query capabilities, pickers, and creation uis for each type. Adding an identifier to QueryCapability and Dialog would address the needs of programmatic clients. Regards, Jim _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
