Date: Tue, 5 May 2009

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

Agenda:

• Receive and process final review comment
• Received comments (since last review) from:
  • PatrickStreule (RTC Work Items)
    1. Ensure concurrent modifications to resources are appropriately handled. Support ETag on GET, utilized on PUT and if does not match response with 412 precondition failed
    2. Misc other items already handled
  • SamPadgett (ClearQuest? )
    1. Need for standard error response element for attended resource creation (redirect URL for web presentation)
       Proposed change is to add something generic, like: <oslc_cm:link rel="alternate" type="text/html" href="record/creationDialog"/>
    2. Misc other items already handled
  • SteveAbrams

    Under "media types" on http://open-services.net/bin/view/Main/CmRestApiV1
    there is a TODO for valid RDF/XML -- where are we on that?
    do we not have a dfinition for application/x-oslc-cm-change-request+json? or is this stricly XML?
    <SKS> awaiting someone to contribute. </SKS>
    application/xml and application/json are still mentioned as formats under "http://open-services.net/bin/view/Main/CmRestApiV1#Create_a_new_change_request" -- I think you mean application/x-oslc-cm-change-request+xml and application/x-oslc-cm-change-request+jsonl there, although if so, we do need the spec for the JSON format.
    <SKS>well, I think we should say both. the more general application/* gives us flexibility on our implementations and we both (RTC and CQ) already support this </SKS>
    For attended resource ccreation, are we currently saying that you can either prpovide a 'ticket' or communicate back from the iFrame as in the picker case? If so, we're making our clients lives 2x as hard as they need to be, since they have to be prepared for either response.
    <SKS>The "ticket" support for attended resource creation is optional. So no hard requirement to support it. We can drop if needed. </SKS>
    Under "Get a change request" -- you do specify that the json format is allowed, but don't say what it is. Also -- are we requiring that requests text/html and application/xhtml+xml be satisfied? Are we providing a web UI in response to those requests?\
    <SKS>Yes, we are redirect to our Web UI presentations in these cases</SKS>
    "The formats returned MAY not represent the underlying service provider's data model." -- this actually doesn't make much sense to me; I'd strike it completely since we're not talking about underlying data models anywhere.
    <SKS>This was the result of a comment by Martin, that he wanted us to be clear that it isn't representing the data model. Perhaps it can be rephrased?</SKS>
    Under "Update a change request" - media types need to be updated to fully-qualified oslc media types. I don't think we'll accept plain application/xml or application/json here, do you?
    <SKS>Both RTC and CQ implementations already do support these media types. If the element in not known, appropriate errors are returned. In fact, I recently learned the RTC uses text/xml and we don't have it in our specs anywhere.</SKS>
    Under "Partial update of a change request" -- we should word this more clearly. http://foo.com/workitem/1234 is a different resource than http://foo.com/workitem/1234?propperties="headline" -- so this is not partial update of a change request: it's total update of a smaller resource. This may sound like a nit, but it's an important point (to me). Now that I think about it, we're surfacing the same incorrect mental model under both "Selected Properties" and "Response Properties" -- that should be phrased to reflect the fact that there are additional, logical resources that include only specific properties, with URLs that can be computed as described here.
    <SKS>we can take a pass at better wording</SKS>
    The "Selected Properties" discussion needs to be connected to the resources that support it in some way.
    <SKS>suggestions?</SKS>
    On pagination: MUST be limited in size, or SHOULD be? I thought this was an advisory request...
    <SKS>made the change</SKS>
    Where are we on the discussion of what the media types are for inlined and subsetted resources?
    <SKS>We have concluded that discussion with a result that we would not inline any resourse beyond the first level. If we do expand the first level, then only wildcard is supported.</SKS>
    Under http://open-services.net/bin/view/Main/OslcServiceProviderCatalogV1:
    "The media type of a Service Provider Catalog Document is REQUIRED to be..." should say "MUST be"
    <SKS>According to RFC2119 MUST=REQUIRED:
    1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.
    </SKS>
    

    • I think this wa basically written by Jim D, right?? This doesn't use the table to describe the required and optional attributes as our other ones do; I don't know if it's worth adding that table at this point but it is an inconsistency.

    <SKS>Known, other things have taken priority and no one has updated</SKS>
    http://open-services.net/bin/view/Main/CmServiceDescriptionV1
    says to 'rewrite with OslcServiceProviderCatalogV1" but this still needs doing.
    <SKS>correct, a todo</SKS>
    is this resource RDF/XML?
    <SKS>Yes, it validates with RDF/XML validators</SKS>
    
    http://open-services.net/bin/view/Main/CmResourceDefinitionsV1
    Do we need to say that this resource accepts 'open content'? Or something to indicate that it MAY contain elemements not specified here, and indicate what the server should do when POSTs come in with additional content? Perhaps indicate in the "Introduction" here that the reason for this being a minimal resource.
    <SKS>we should it supports open content</SKS>

  • SteveSpeicher
    1. Add text/xml support
    2. Add details about inlining resources in ATOM responses
  • misc:
    1. Need to update JSON and XML
• 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

Minutes:

Attendees: SteveSpeicher, SteveAbrams, PatrickStreule, RobertElves, ScottBosworth, GargDang? , SamitMetha? , CarolynPampino

• Ensure concurrent modifications to resources are appropriately handled. Support ETag on GET, utilized on PUT and if does not match response with 412 precondition failed
  Accepted (with need to provide clarification that we are restating what HTTP does)
• Need for standard error response element for attended resource creation (redirect URL for web presentation)
  Align with 303 and use Location header SteveSpeicher to follow up
• Inlining what media type use for 2nd request
• Inlining status codes on missing fields
• Returned content when required items are not given (it is not a oslc cr)