Uploaded image for project: 'OASIS Content Management Interoperability Services (CMIS) TC'
  1. OASIS Content Management Interoperability Services (CMIS) TC
  2. CMIS-61

SOAP methods seem to be covered in all parts of the spec, instead of just contained to Part III, the SOAP portion.

    XMLWordPrintable

    Details

    • Proposal:
      Hide

      Revise Part I to not refer to "methods" but rather functionality. The parity between this and the SOAP methods is fine, but perhaps wording to make it less "soap-like" would help.

      Part II should refer to functionality, not SOAP methods.

      Parts II and III should be peers (perhaps not numbering parts but simply titling them would be appropriate.)

      Revised Proposal:

      Issue was closed with a note saying the methods are still in Part 1, but with reduced protocol-specific stuff.
      I'd propose then that the method descriptions be removed from the REST section, and update the resource descriptions so that they refer to the methods in Part 1. As an example:

      • Resource: Document, Method: PUT, Maps to: updateProperties
        o Resource uri uniquely identifies the specific document and version.
        o Input is an Entry document, ID attribute must be validated, other attributes are ignored, except for properties.
        o Content stream properties are not updated (see Resource ContentStream).
        o Optional inputs are HTTP query parameters.
        o Output is formatted as an Entry document.
      Show
      Revise Part I to not refer to "methods" but rather functionality. The parity between this and the SOAP methods is fine, but perhaps wording to make it less "soap-like" would help. Part II should refer to functionality, not SOAP methods. Parts II and III should be peers (perhaps not numbering parts but simply titling them would be appropriate.) – Revised Proposal: Issue was closed with a note saying the methods are still in Part 1, but with reduced protocol-specific stuff. I'd propose then that the method descriptions be removed from the REST section, and update the resource descriptions so that they refer to the methods in Part 1. As an example: Resource: Document, Method: PUT, Maps to: updateProperties o Resource uri uniquely identifies the specific document and version. o Input is an Entry document, ID attribute must be validated, other attributes are ignored, except for properties. o Content stream properties are not updated (see Resource ContentStream). o Optional inputs are HTTP query parameters. o Output is formatted as an Entry document.
    • Resolution:
      Hide

      The updated CMIS spec still refers to abstract methods... but has removed a bunch of the protocol-specific references that talk about SOAP vs. REST.

      Hopefully this clears up the issue. I'm not sure how to go farther in terms of clarification here (because having abstract method definitions as contracts that all bindings must meet seems like the only way to ensure uniformity of functionality at the level that we require.)

      Show
      The updated CMIS spec still refers to abstract methods... but has removed a bunch of the protocol-specific references that talk about SOAP vs. REST. Hopefully this clears up the issue. I'm not sure how to go farther in terms of clarification here (because having abstract method definitions as contracts that all bindings must meet seems like the only way to ensure uniformity of functionality at the level that we require.)

      Description

      Some of our developers are working actively on a prototype. As new readers of the spec, they've provided this feedback:

      1. Part I describes the data model and methods. The methods are very SOAP-like, it would be best to keep these methods in part III, the SOAP section. Part I should cover the data model and functionality.
      2. Part II shouldn't refer to SOAP methods, since this is the REST sections.
      3. Part II and III should be peers

        Attachments

          Activity

            People

            • Assignee:
              ethang Ethan Gur-esh
              Reporter:
              ryan.mcveigh Ryan McVeigh (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: