Reconciling 2.0 domain specification base requirements with OSLC Core 3.0

I went through the AM 2.0 specification
comparing the base requirements with CM 3.0. I found the following potential
incompatibilities with Core 3.0:

1. RDF serialization format - AM specifies
MUST for RDF/XML which is OK, but doesn’t mention turtle or json-ld. -
Recommendation: change to follow Core 3.0 RDF serialization formats, including
proposal to change core RDF serialization formats clauses.

2. Discovery - AM says ServiceProvider
resource is MUST, Core MAY - Recommendation: ok to strengthen compliance
level in a domain spec, so no problem. However this should just say MUST
support OSLC discovery, and need not say exactly how. Servers just follow
core which already covers OSLC 2.0 discovery compatibility.

So not much there. Other domain specs
should retain the base capabilities and supporting text from the OSLC 2.0
specifications unless there's some compelling reason they can't. In particular,
the RM spec should not have copied the CM base requirements, but instead
stick with the ones in the RM 2.0 spec.

Here's the details:

Architecture
Management

Thu Jan 11 09:39:53
EST 2018

Analyzing the differences
between CM
3.0 and AM
2.0 Base
Requirements. 
The result of this
analysis applies to the subsections of the document as well. Ideally these
would be cloned and be quite similar for each domain specification.

CM
3.0 RequirementLevelMeaningAM
2.0 Differences
Unknown
properties and contentmay/ mustOSLC
servers mayignore unknown content and OSLC clients mustpreserve unknown contentClient
MUST is in a separate entry.
Resource
OperationsmustOSLC
service mustsupport resource operations via standard HTTP operations
Resource
PagingmayOSLC
servers mayprovide paging for resources but only when specifically requested by clientPaging
is SHOULD for query results, MAY on large resource entity response bodies.
Partial
Resource RepresentationsmustOSLC
servers mustsupport request for a subset of a resource’s properties via the oslc.properties
URL parameter retrieval via HTTP GETAM
is MAY support selective properties
Partial
UpdatemayOSLC
servers maysupport partial update of resources using [LDPPatch], or via HTTP PUT.
Discoverymay/ shouldOSLC
servers shouldprovide a ServiceProvider resource for Core v2 compatibility, mayprovide a ServiceProviderCatalog, and mayprovide other forms of discovery described in Core 3.0 Discovery.Specifically
states MUST provide ServiceProvider resource. Servers MAY support ServiceProviderCatalog
Creation
FactoriesmustOSLC
servers mustprovide LDPC creation factories to enable resource creation of Change Management
resources via HTTP POSTCreation
factory capability is MAY, and also servers MAY support creation factories
in other resource serialization formats indicated with oslc:usage.
Query
CapabilitiesshouldOSLC
servers shouldprovide query capabilities to enable clients to query for resourcesquery
capability is a MUST
Query
Syntaxshould/ mayOSLC
query capabilities shouldsupport the OSLC Core Query Syntax and mayuse other query syntax
Delegated
UI Dialogsmust/ shouldOSLC
Services mustoffer delegated UI dialogs (creation and selections) specified via OSLC
Core 3.0 Delegated Dialogs and shouldinclude discovery through a ServiceProvider resource for OSLC v2 compatibilityDelegated
selection UI is SHOULD, delegated creation dialog is separate entry and
MAY.
UI
PreviewshouldOSLC
Services shouldoffer UI previews for resources that may be referenced by other resources
specified via OSLC Core 3.0 Preview and shouldinclude discovery through a server resource for OSLC v2 compatibility
AuthenticationmayOSLC
Services shouldfollow the recommendations for Authentication specified in [OSLCCore3]SHOULD
support one of the OSLC Core recommendations, Has separate MAY for each
one (HTTP Basic, OAuth, Form)
Error
ResponsesshouldOSLC
Services shouldprovide error responses using OSLC Core 3.0 defined error formats
Turtle
RepresentationsmustOSLC
servers mustprovide a Turtle representation for HTTP GET requests and shouldsupport Turtle representations on POST and PUT requests.
RDF/XML
RepresentationsshouldOSLC
servers shouldprovide an RDF/XML representation for HTTP GET requests and shouldsupport RDF/XML representations on POST and PUT requests for compatibility
with Change Management 2.0.RDF/XML
is MUST
XML
RepresentationsshouldOSLC
servers shouldprovide a XML representation for HTTP GET, POST and PUT requests that conform
to the Core 2.0 Guidelines for XML.
JSON
RepresentationsmustOSLC
servers mustprovide JSON-LD representations for HTTP GET, POST and PUT requests that
conform to the Core Guidelines for JSON-LD
HTML
RepresentationsshouldOSLC
servers shouldprovide HTML representations for HTTP GET requests

Other Differences:
Servers
MUST use absolute URIs - not sure this is a good idea, but its there, so
ok to keep it.
Servers
MUST support If-Match header on PUT and DELETE - note mentioned in CM,
but may be in Core 3.0
Unique
AM Link Type Query Capability
CM does
not specify which HTTP resource operations may, must, or should be provided
- AM say PUT & DELETE are SHOULD, may be covered in Core.
Specifically
states servers SHOULD support paging for queries
Potential conflicts
with OSLC Core 3.0:
RDF serialization
format - AM specifies MUST for RDF/XML which is OK, but doesn’t mention
turtle or json-ld. - Recommendation: change to follow Core 3.0 RDF serialization
formats
Discovery
- AM says ServiceProvider resource is MUST, Core MAY - Recommendation:
ok to strengthen compliance level, so no problem, should just say MUST
support OSLC discovery, and need not say exactly how. Servers just follow
core.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575