[oslc-core] programmatic selection of creation factories
Arthur Ryman
ryman at ca.ibm.com
Thu Jun 3 20:55:29 EDT 2010
Nick,
The Shape has a property, oslc:describes, that refers to the type. The
type doesn't change between implementations, but the Shape resource could
since implementations could add properties to the type.
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:
Nick Edgar/Ottawa/IBM at IBMCA
To:
Jim des Rivieres/Ottawa/IBM at IBMCA
Cc:
oslc-core at open-services.net, David M Johnson <dmjohnso at us.ibm.com>, John
Wiegand <John_Wiegand at us.ibm.com>, oslc-core-bounces at open-services.net
Date:
05/31/2010 07:53 PM
Subject:
Re: [oslc-core] programmatic selection of creation factories
Sent by:
oslc-core-bounces at open-services.net
+1. We have this issue with the OSLC Automation spec and prototype, where
we have queryable collections for plans, results, and contributions.
Currently our service document includes:
<oslc:service>
<oslc:Service>
<oslc:queryCapability>
<oslc:QueryCapability>
<dc:title>Automation Plan Query</dc:title>
<oslc:label>plansquery</oslc:label>
<oslc:queryBase rdf:resource="
https://localhost:9443/jazz/oslc/contexts/_xLlHcBipEd6zruFy5LB2ow/automation/plans
"/>
<oslc:shape rdf:resource="
https://localhost:9443/jazz/oslc/automation/shapes/plansquery"/>
</oslc:QueryCapability>
</oslc:queryCapability>
<oslc:queryCapability>
<oslc:QueryCapability>
<dc:title>Automation Result Query</dc:title>
<oslc:label>resultsquery</oslc:label>
<oslc:queryBase rdf:resource="
https://localhost:9443/jazz/oslc/contexts/_xLlHcBipEd6zruFy5LB2ow/automation/results
"/>
<oslc:shape rdf:resource="
https://localhost:9443/jazz/oslc/automation/shapes/resultsquery"/>
</oslc:QueryCapability>
</oslc:queryCapability>
</oslc:Service>
</oslc:service>
We don't include the query capability for contributions because it's
currently a nested collection under the URI for a result,
e.g.
https://localhost:9443/jazz/oslc/contexts/_xLlHcBipEd6zruFy5LB2ow/automation/results/
{resultUUID}/contributions
and we have no way of describing that at top-level. But that's a separate
issue.
Also, our use of oslc:label is probably wrong - it's intended to be a
short, human-readable label. However, I would suggest that this indicates
the implementer thought there should be a machine-readable id.
Rather than providing a dc:identifier with some value that would have to
be well known by consumers, perhaps the service could describe the element
type as a property, similar to rdf:type but describing the type of
elements in the collection, or produced by the factory.
e.g.
<oslc:elementType>http://open-services.net/xmlns/automation/1.0/Plan
</oslc:elementType>
I don't think it suffices to rely on the shape description. Clients
should not have to fetch the shape resource to determine the element type,
and clients cannot rely on the shape URL since it's
implementation-specific.
Or perhaps some subset of the shape could be inlined.
If there can be more than one query collection / factory for the same
element type, though, an additional identifier would be needed.
Nick Edgar
RTC Build component lead
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: 2010/05/31 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
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list