History   View   Links to this page Revision from: 2012 September 7 | 05:20 pm
This is the revision from 2012 September 7 at 05:20 pm   View the current live version of the article.

Introduction

This page on the wiki is where will document issues raised against the version 2 of the AM 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 2.0 Compliance

  1. RESOLVED - The service provider catalog resource may not be required (MUST -> MAY). A service provider may support a single context. All the information required for a client to use the service can be obtained in the servce provider resource. The service provider resource however needs to be explicitly made a MUST.
  2. RESOLVED - It may be possible for a provider to not require authentication, and still provide read only serivices to clients. Required athentication is a SHOULD.
  3. RESOLVED - Remove the comment on RDF/XML mapping in the OSLC Core. We want to detach ourselves from specific mappings and rules for mappings, reliying on accepted industry standards and products. Not part of this or the core specification.
  4. RESOLVED - Query should be Query Capability (in summary table). The query capability should be a MUST with the condition that only the olsc.where and olsc.prefix parameters are required to be implmented. Do not put language about potential constraints.
  5. RESOLVED - If query capability is moved to a MUST, then we can make delegated UI selection as SHOULD.
  6. RESOLVED - Role of Atom feeds in responses. Early on in this workgroup (almost a year ago) we decided that all responses that involved collections of things should use Atom as the standard response. The OSLC Core 2.0 now requires that all responses support at least a minimum rdf/xml (note not Atom). Since we are required to support this type of response even for query capability, it doesn’t make as much sense to recommend that queries can respond with Atom. We should not require (MUST or SHOULD) Atom responses anywhere - clients are expected to receive any rdf/xml response.

Other

  1. TABLED - 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. RESOLVED - Should we explicitly state in the specification that all RDF/XML documents MUST begin with outer rdf:RDF element (so as to support additional rdf:Description elements as mentioned in linking guidance). Not necesary, there is verbage in the core spec that states that client should be aware of the different styles of RDF/XML.
  3. DEFERRED- There are a couple of dcterms (relation, requires, and references) that we should consider including in as a base property (zero-or-many).
  4. RESOLVED - We should use rdfs:label and rdfs:comment properties instead of dcterms:title and dcterms:description for LinkType resources. This is to be consistent with their usage in the RDF documents from the W3C and Dublin Core.