This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

Date: Sep 9 2009



Attendees: MichaelPena, IngridJorgensen, ScottFairbrother, JimConallen, ScottBosworth, IanGreen, PaulMcMahan

  • Introduced Inga to workgroup
  • Reviewed scenarios w.r.t. what is in scope for v 1.0 specifications
    • Scenarios A and B received some polished since last workgroup meeting and are in scope
    • The workgroup needs more discussion about scenario C about metadata and workflow, potentially across OSLC. It is not in scope for v1.0 but discussion about that scenario will continue for a future version of the spec
    • The reporting and versioning scenarios are not in scope
    • Some concerns were raised w.r.t. whether a 1.0 spec could really be considered complete without some type of query API. Paul to investigate what might be accomplished in the 1.0 time frame, and whether the current scenarios might call out an implicit need for query or whether a separate scenario specifically about search might be in order.
  • Reviewed the Draft specifications
    • There was a lot of good conversation about the REST API specification in particular
      • We are taking the position that the XML namespace prefixes are not part of the specification. They are only used in the specification document for readability.
      • A good point was raised which is that if the namespace prefixes are not part of the standard then they should not be used in the selective properties. The full namespace URI should be used instead.
      • Also there was some discussion about the usage of "MAY" vs. "MUST". There are certain areas of the draft spec such as the part about ETag and If-Match headers where "MAY" should probably be changed to "MUST", or the spec should not prescribe any behavior at all.
      • Also discussed the usage of selective properties for update requests. Q: Why use selective properties instead of just providing the portion of the resource XML that needs to be updated? A: so that properties can be deleted. Q: Why not use empty elements for property deletion? A: Because there may be need to be a distinction between an empty property and a null property, i.e. a property that exists with an empty value vs. a property that does not exist at all.
    • Briefly discussed the resource XML and service description formats
      • A JSON resource format spec is not being provided in v1.0
      • These look a lot like the corresponding CM specs
      • We're taking a minimalist approach with the resource XML spec and allowing for extensions to that XML via namespaces
Topic revision: r4 - 06 Nov 2009 - 22:34:04 - PaulMcMahan
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback