Date: Wednesday, 29 April 2009

Time: 12:00 PM Eastern, 9:00 AM Pacific, 6:00 PM Zurich
(contact SteveSpeicher if you'd like to participate)

Agenda:

• Tasktop to provide implementation report
• Receive and process final review comment
• Determine next step for convergence:
  • Finalize review of specifcations by 29-April
  • Each contributing organization will review Terms of Use by 29-April
  • Finalize and respond to feedback by 8-May
  • Each contributing orgnization will produce a patent covenant per the Terms of Use by 15-May and post to wiki CmSpecificationV1Covenant
  • Specifications CmSpecificationV1 will be locked (non-editable) and each contributing organization's covenant on or shortly after 15-May

Comments received so far:

-- RandyVogel - 29 Apr 2009

• REST API spec: Why isn’t delete available for a collection? This seems like it would be a valuable function.

-- SteveSpeicher - 29 Apr 2009 What scenario are you thinking of? My concern was that there is a URL say {query-url}, which always returns a collection (based on query parameters). We would not necessarily want to support bulk delete of these (we see delete as a rarely use case in CM).

• Resource Definition spec: Should Creator be required? I would think it makes sense. Should description be optional? I think it’s best practice to provide a description but if we’re mass loading we might want to focus on the title first and then go back later to enter a description. The field tab “subject” is mis-leading – I was thinking it could be the title but it’s actually a collection of keywords so should it be tagged “keywords”?

-- SteveSpeicher - 29 Apr 2009 For creator and description makes sense, let's discuss with the WG.

is defined by the Dublin Core spec. It's definition is very close to what most naturally think of as "tags" or "keywords". Since this is more-or-less a transport format, we try to leverage Dublin Core as much as possible, even if the element name isn't the best choice.

• Query Syntax spec: Is there a reason why “and” is the only operator and “or” is not available? Has there been any talk of an enhanced query that will return only certain data rather than the whole records?

-- SteveSpeicher - 29 Apr 2009 This "simple" query syntax was intended for use as encoded in URLs. If we added or, we ran into complexities with needing grouping which greatly complicates it. For most of the queries we needed for 1.0, it was a small set. We look to expand this in future spec's and support a more robust POST-based method.

You can request a subset of information using the ?oslc_cm.properties= parameter, indicating only the parameters you want.

-- GaryDang - 29 Apr 2009

• REST API spec: the “oslc_cm.pageSize” specifies the max number of returned items. Is there a way for the requester to know we are getting partial data (e.g. if query returns 51 items but requester sets pageSize=50)

-- SteveSpeicher - 29 Apr 2009

Here's a sample from my server:

https://localhost:9443/jazz/cqrest/repo/7.0.0/db/SAMPL/record?rcm.type=Defect&oslc_cm.query=state=%22Submitted%22&oslc_cm.pageSize=5

Which it looks like we have added a CQ-specific field in the result to indicate what the real size is. You can infer that if there is not a "next" link then there are no more entries.
We can discuss whether we should add this "total size" element to the results format.

Here's a fragment of the CQ response from the request URL above:
<resultSetSize xmlns="http://www.ibm.com/cm/clearquest/0.1">1691</resultSetSize>

Minutes:

Attendees: SteveSpeicher, MikKersten, RobertElves, RandyVogel, PatrickStreule, ScottBosworth, SteveAbrams

Minutes:

• Validated agenda (no new items)
• Tasktop implementation report:
  • working towards basic structure and usable interface for Mylyn base contribution
  • would like have something like a user-friendly identifier/name, can be used for key in local index
  • would like clarification on <dc:identifer> usage in ChangeRequest? spec
  • better support will be avaible when schema is available in later OSLC CM spec (query and task editor)
• Reviewed next steps for convergence, no outstanding issues. IBM, Tasktop and Accenture are on target for May 8th finalization.
• Received comments so far (see agenda):
  • RandyVogel #1: WG viewed this as out of scope for 1.0. Asked that Randy provide a scenario where this would be needed.
  • RandyVogel #2: WG decided to make description optional and leave subject. Spec will be updated to clarify what is required on GET versus POST/PUT
  • RandyVogel #3: WG agrees that or is out of scope of 1.0. There is or'ing of values using the 'in' operator. Or and grouping will be considered for future specs.
  • GaryDang #1: WG agrees that this is valuable and can be contained in 1.0. Will produce an OSLC CM namespaced element to include in results formats, such as <oslc_cm:totalCount>
• Requested additional meeting on May 6th (or some day before May 8th), exact time & day TBD