Why does RTC work item service provider OSLC request return nested oslc:creationFactory elements?
The response to an RTC work item service provider OSLC request, such as https://<host>:<port>/ccm/oslc/contexts/_pyf14FrmEeWs66yN_e1diA/workitems/services.xml, contains nested <oslc:creationFactory> elements:
...
<oslc:creationFactory>
<oslc:CreationFactory>
<dcterms:title rdf:parseType="Literal">Location for creation of Task change requests </dcterms:title>
<oslc:usage rdf:resource="http://open-services.net/ns/cm#task"/>
<oslc:usage rdf:resource="http://open-services.net/ns/cm#requirementsChangeRequest"/>
<oslc:resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<oslc:resourceType rdf:resource="https://sport6.rtp.raleigh.ibm.com:9463/ccm/oslc/types/_pyf14FrmEeWs66yN_e1diA/task"/>
<oslc:resourceShape rdf:resource="https://sport6.rtp.raleigh.ibm.com:9463/ccm/oslc/context/_pyf14FrmEeWs66yN_e1diA/shapes/workitems/task"/>
<oslc:creation rdf:resource="https://sport6.rtp.raleigh.ibm.com:9463/ccm/oslc/contexts/_pyf14FrmEeWs66yN_e1diA/workitems/task"/>
</oslc:CreationFactory>
</oslc:creationFactory>
<oslc:creationFactory>
<oslc:CreationFactory>
<dcterms:title rdf:parseType="Literal">Location for creation of Story change requests </dcterms:title>
<oslc:usage rdf:resource="http://open-services.net/ns/cm#planItem"/>
<oslc:resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<oslc:resourceType rdf:resource="https://sport6.rtp.raleigh.ibm.com:9463/ccm/oslc/types/_pyf14FrmEeWs66yN_e1diA/com.ibm.team.apt.workItemType.story"/>
<oslc:resourceShape rdf:resource="https://sport6.rtp.raleigh.ibm.com:9463/ccm/oslc/context/_pyf14FrmEeWs66yN_e1diA/shapes/workitems/com.ibm.team.apt.workItemType.story"/>
<oslc:creation rdf:resource="https://sport6.rtp.raleigh.ibm.com:9463/ccm/oslc/contexts/_pyf14FrmEeWs66yN_e1diA/workitems/com.ibm.team.apt.workItemType.story"/>
</oslc:CreationFactory>
</oslc:creationFactory>
...
From what I find at OSLC Core Specification Version 2.0 - Resource: Creation Factory, the <oslc:creationFactory> element isn't allowed to contain a nested <oslc:creationFactory> element. So I would think that RTC OSLC response isn't valid. Is my understanding correct? Is this an RTC OSLC defect?
Accepted answer
The result that you got looks a bit strange. It should've looked like
If you look at the "Resource: Service" table in the specification, there two elements are not the same thing. Note that "queryCapability" has the same "nestedness".
< oslc:creationFactory>I know that Lyo OSLC4J works with the service provide document just fine, so it should be correct. QM and RM return something similar (re: nested).
< oslc:CreationFactory>
......
If you look at the "Resource: Service" table in the specification, there two elements are not the same thing. Note that "queryCapability" has the same "nestedness".
| Prefixed Name | Occurs | Read-only | Value-type | Represen-tation | Range | Description |
|---|---|---|---|---|---|---|
oslc:domain
|
exactly-one | True | Resource | Reference | n/a | Namespace URI of the specification that is implemented by this service. In most cases this namespace URI will be for an OSLC domain, but other URIs MAY be used. |
oslc:creationFactory
|
zero-or-many | True | Local Resource | n/a |
oslc:CreationFactory
|
Enables clients to create new resources |
oslc:queryCapability
|
zero-or-many | True | Local Resource | n/a |
oslc:QueryCapability
|
Enables clients query across a collection of resources |
oslc:selectionDialog
|
zero-or-many | True | Local Resource | n/a |
oslc:Dialog
|
Enables clients to select a resource via UI |
oslc:creationDialog
|
zero-or-many | True | Local Resource | n/a |
oslc:Dialog
|
Enables clients to create a resource via UI |
oslc:usage
|
zero-or-many | True | Resource | Resource | n/a |
An identifier URI for the domain specified usage of this service. If a service provider has multiple services, it may designate the primary or default one that should be used with a property value of
http://open-services.net/ns/core#default
|
Comments
Donald, thanks for the response.
I realize the there was a capitalization problem in the example XML I posted. I did a copy/paste of the XML, but for some reason all of the element tags (text between < and >) were converted to lower case.
I still think nesting oslc:CreationFactory in a oslc:creationFactory looks strange, but I no longer think it's the cause of my Lyo OSLC4J problem.