OSLC Architectural Direction for AM Initial Specification

When it comes to collaborative integration across domains it is clear that architectural approaches need to be compatible, and ideally the same. Therefore for the initial release ofthe AM specifications the architectural direction will follow the lead blazed by the Change Management team primarily with their 1.0 Architectural Direction document but also with an eye and consideration on the more recent 2.0 Architectural Direction working draft.

Architectural Decisions for OSLC AM 1.0

1. Services will be discoverable by traversing configuration collections until a service specification document is returned.
2. Provide a miminal set of properties for resources based on Dublin Core?
   1. Usage of dc:modifed , dc:title, and dc:creator for support in all resources, assisting in reporting tools, feed readers and other synchronization tools.
3. Default format for a collection of resources is ATOM syndication format (with content inline vs. reference)
   1. There is a need for a lighter-weight XML formats (ATOM-like, possibly RDF-ish)
      • This format will be used when there are collections within ATOM responses
      • ATOM responses will included by links to resource information, as well as inline resource properties.
4. Resource links are handled as a multi-valued property on a resource
   • There are no spec'd requirements on whose responsibility storing cross repository links (uni-directional, bi-directional)
5. There will be a simple GET-based query syntax
6. TODO: Is there a requirement to request the amount of properties returned in response?
7. Retruned formats are based on Accept header
   1. Resources will support at least application/xml as request and response format (and application/json ?)
   2. Presentations for resources can be requested using the HTTP Accept header with values such as text/html or application/xhtml+xml
8. Model Element creation and modification
   1. do we require service implementations to permit for all modeling types? Can this be optional for some types?

-- JimConallen - 20 Aug 2009