Revision: OSLC Architecture Management v3.0 Specification Issues

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. OPEN - 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?

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).
2. OPEN - There are a couple of dcterms (relation, requires, and references) that we should consider including in as a base property (zero-or-many).
3. CLOSED - Deprecate Link Type Resource in favor of directly resolvable predicates.
4. OPEN - Definition of Diagram resource type.
5. DEFERRED - Pre-defined queries.
6. OPEN - Common AM link types.