[oslc-core] programmatic selection of creation factories

[Arthur Ryman]

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 at IBMCA
To:
Scott Bosworth <bosworth at us.ibm.com>, David M Johnson 
<dmjohnso at us.ibm.com>, Steve K Speicher <sspeiche at us.ibm.com>
Cc:
oslc-core at open-services.net, John Wiegand <John_Wiegand at us.ibm.com>
Date:
05/31/2010 09:57 AM
Subject:
[oslc-core] programmatic selection of creation factories
Sent by:
oslc-core-bounces at open-services.net



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
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net