History   View   Links to this page 2013 June 20 | 09:42 am

Introduction

This page on the wiki is where will document issues raised against the version 3 of the OSLC Architecture Management specification.

Here’s what the states mean:

  • OPEN - indicates that we have no response for the issue yet
  • RESOLVED - indicates that we have a response that we believe resolves the issue
  • CLOSED - issue has been resolved and the resolution has been reviewed by the WG
  • DEFERRED - indicates that issue will be addressed in after the specification is final.
  • TABLED - indicates that issue will be reconsidered at some later but unspecified date

Issues

Core 3.0 Compliance

  1. OPEN - The Core defines a partial update specification that our specification has yet to adopt because of its complexity to implement. Should we recommend its adoption for v3?.
  2. OPEN - The Core specifies JSON and XML representation guidance. Do we also include these as MUST/SHOULD/MAY?
  3. RESOLVED - Some specifications state that “OSLC services MAY provide paging for resources but only when specifically requested by client”. In AM domain, some resources are very very big, and the client might not realize this. Should we allow the server to decide on paging, and require clients to expect paging in all rdf responses? Specify that the service provider MAY provide paged responses, whether the client requests it or not. Clients MUST be capable of accepting a paged response.
  4. RESOLVED - The Core is expected to align with the Linked Data Basic Profile and recommend that Turtle be the one MST representation format, and that RDF/XML be avoided. Should we adopt Turtle as a MUST, and mention RDF/XML as a MAY (only because in the previous version of this specification is was a MUST)? Following Core recommendations

Other

  1. OPEN - Can we include some mechanism clients can programmitcally determine exactly which aspects of query support are implemented (and by extension, any other aspect of the specification that is optional). Action: We need to provide a use case scenario where this is necessary. Perhaps we can document how a UML resource provider might permit OCL queries on its resources.
  2. OPEN - The dcterms; requires and references should be considered for inclusion as a base property (zero-or-many).
  3. CLOSED - Deprecate Link Type Resource in favor of directly resolvable predicates.
  4. CLOSED - Definition of Diagram resource type.
  5. DEFERRED - Pre-defined queries.
  6. OPEN - Common AM link types.
  7. OPEN - MDD Transformations.