[#CMIS-98] There are CMIS properties that duplicate APP/ATOM information

OASIS Content Management Interoperability Services (CMIS) TC

There are CMIS properties that duplicate APP/ATOM information

Created: 04/Mar/09 05:05 PM Updated: 11/Jan/10 07:31 PM

Component/s:

REST/AtomPub Binding

Affects Version/s:

Draft 0.50, Draft 0.60

Fix Version/s:

Draft 0.62

Proposal:

Reduce duplication where data is already present in the ATOM representation. Order of precedence: atom then cmis for cmis properties that are mapped to atom.

Description

« Hide

I think this is reasonably significant - so I chose the Critical priority. This may also be most appropriate to break up into separate issues, but for simplifying discussion I'll report this as a single issue and list all of the various duplications we've found.

1. part II p. 19 "All CMIS properties will be exposed in CMIS properties tag even if they are duplicated in an atom element". Why are there duplicates? This just seems to clutter things...

2. "Atom:Id will be the URI of the resource"
  - Why is there a CMIS URI property (enumPropertiesBase Uri) that simply duplicates what should be in atom:id?
  - Is there a case where just one of these will appear and that's why sometimes it's duplicate?

          <atom:id>http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001</atom:id>
          <cmis:propertyString cmis:propertyType="string" cmis:name="Uri">
              <cmis:value>http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001</cmis:value>
          </cmis:propertyString>

3. "App:edited will be CMIS:lastModifiedDate"

4. "Link with relation self will be CMIS:uri"

    <atom:link rel="self" href="http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001" />
    <cmis:propertyString cmis:propertyType="string" cmis:name="Uri">
        <cmis:value>http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001</cmis:value>
    </cmis:propertyString>

5. "Published will be CMIS:createdDate"

    <atom:published>2009-02-27T10:26:50.625-07:00</atom:published>
    <cmis:propertyDateTime cmis:propertyType="datetime" cmis:name="CreationDate">
        <cmis:value>2009-02-27T10:26:50.625-07:00</cmis:value>
    </cmis:propertyDateTime>

6. "Atom:author will be CMIS:creator" creator? does this mean createdBy?

          <atom:author>
              <atom:name>weblogic</atom:name>
          </atom:author>
          <cmis:propertyString cmis:propertyType="string" cmis:name="CreatedBy">
              <cmis:value>weblogic</cmis:value>
          </cmis:propertyString>

7. "Author/name will be CMIS:createdBy "

   - name? or does this mean contributor? or was that just a clarification for author?
   - oh, I see, nested element name...that was confusing...maybe similar phrases should be used (Atom:author was used before, as was creator, instead of createdBy)

          <atom:contributor>
              <atom:name>weblogic</atom:name>
          </atom:contributor>

Description

I think this is reasonably significant - so I chose the Critical priority. This may also be most appropriate to break up into separate issues, but for simplifying discussion I'll report this as a single issue and list all of the various duplications we've found. 1. part II p. 19 "All CMIS properties will be exposed in CMIS properties tag even if they are duplicated in an atom element". Why are there duplicates? This just seems to clutter things... 2. "Atom:Id will be the URI of the resource" - Why is there a CMIS URI property (enumPropertiesBase Uri) that simply duplicates what should be in atom:id? - Is there a case where just one of these will appear and that's why sometimes it's duplicate? <atom:id>http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001</atom:id> <cmis:propertyString cmis:propertyType="string" cmis:name="Uri"> <cmis:value>http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001</cmis:value> </cmis:propertyString> 3. "App:edited will be CMIS:lastModifiedDate" 4. "Link with relation self will be CMIS:uri" <atom:link rel="self" href="http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001" /> <cmis:propertyString cmis:propertyType="string" cmis:name="Uri"> <cmis:value>http://localhost:7001/drtWebApp/cmis/children/BEA_ExtendedRepository/4001</cmis:value> </cmis:propertyString> 5. "Published will be CMIS:createdDate" <atom:published>2009-02-27T10:26:50.625-07:00</atom:published> <cmis:propertyDateTime cmis:propertyType="datetime" cmis:name="CreationDate"> <cmis:value>2009-02-27T10:26:50.625-07:00</cmis:value> </cmis:propertyDateTime> 6. "Atom:author will be CMIS:creator" creator? does this mean createdBy? <atom:author> <atom:name>weblogic</atom:name> </atom:author> <cmis:propertyString cmis:propertyType="string" cmis:name="CreatedBy"> <cmis:value>weblogic</cmis:value> </cmis:propertyString> 7. "Author/name will be CMIS:createdBy " - name? or does this mean contributor? or was that just a clarification for author? - oh, I see, nested element name...that was confusing...maybe similar phrases should be used (Atom:author was used before, as was creator, instead of createdBy) <atom:contributor> <atom:name>weblogic</atom:name> </atom:contributor>

Show »

All

Comments

Change History

Sort Order:

[ Permalink | « Hide ]

Florent Guillaume added a comment - 08/Mar/09 10:07 AM

Regarding point 2, note also that:
a. part I specifies that the property Uri is not necessarily mandatory (this is repository-specific),
b. the atom:id may be a simple URN: urn:uuid:ed19fab4-c228-482a-afde-091d8a6525df and this should not be equated with the atom links which could be http://localhost:8080/cmis/object/ed19fab4-c228-482a-afde-091d8a6525df

[ Permalink | « Hide ]

David Caruana added a comment - 09/Mar/09 06:25 AM

What is the purpose of the URI property? What, if provided, does the URI represent? Can it be removed from the spec?

[ Permalink | « Hide ]

David Caruana added a comment - 09/Mar/09 06:37 AM

One of the difficulties in resolving duplicates is the sharing of the schema between the two bindings. The problem does not exist in Web Services.

Ideally, CMIS extends the AtomPub binding only where necessary, mapping repository concepts to AtomPub concepts where applicable (which it does aim to), but unfortunately it also currently duplicates. This also adds complication to create & update semantics.

Essentially, it's a decision on whether to share the schema or provide binding specific schemas.

For example, sharing the schema means a client (and potentially server) implementation can re-use code.

Splitting the schema may result in an AtomPub extension that's more natural, more open to re-use of other AtomPub initiatives e.g. removing cmis:object wrapper, generalising notion of AtomPub properties, using Atom entries to represent hierarchy etc. However, this a radical move from where we are today.

[ Permalink | « Hide ]

Florent Guillaume added a comment - 09/Mar/09 09:33 AM

I would support such a move, given that at the F2F there seemed to be agreement to be as AtomPub-friendly (meaning, follow the spirit) as possible.

[ Permalink | « Hide ]

Ryan McVeigh added a comment - 11/Mar/09 06:34 PM

Part II requires the atom-id == uri. As Atom-id is required by atom and uri isn't required by CMIS, this doesn't make sense. Part I says that the uri is a web-addressable representation of the object. It appears that this can simply be removed from the Atom binding.

[ Permalink | « Hide ]

Ryan McVeigh added a comment - 11/Mar/09 06:39 PM

Regarding David's comments about duplication of cmis properties and atom properites, I have some thoughts:

The spec part II, section "Atom Entry Documents" says: When POSTing an Atom Document, the atom fields take precedence over the CMIS property field for writeable properties.

This appears to me that a client should always give the atom properties precedence over the CMIS properties. If that's the case, what's the value in the CMIS properties again? I'm not sure how much code re-usability there is here, but is that a goal of the spec? I think we should be as AtomPub friendly as we can prior to trying to share code between the two bindings.

Florent: I think that your comment is essentially saying the same thing - we should strive towards reducing the duplication present in the cmis schema where atom already specifies what to do. Is that accurate?

[ Permalink | « Hide ]

Florent Guillaume added a comment - 11/Mar/09 07:03 PM

Ryan: yes, I think we should strive to reduce duplication and have AtomPub-defined information be authoritative. If reasonable.

In addition to the information already mentioned above, there's also:

8. <atom:link rel="cmis-stream" href="..."/> and <cmis:propertyURI name="ContentStreamUri"/> both duplicate <atom:content src="..."/> (which is very similar to, but not exactly the same as, <atom:link rel="edit-media" href="..."/>).

9. <cmis:propertyURI name="ContentStreamMimeType"/> duplicates the optional-but-strongly-suggest-by-Atom "type" attribute of <atom:content>

But as David points out, this makes some parts of the schema unneeded by AtomPub, when it's still required by WS. Which is quite a step to take.

I'll have to think a bit more about this. But I'm sure at least cmis-stream could be removed without problem as it's not a property and is really very redundant.

[ Permalink | « Hide ]

Al Brown added a comment - 10/Apr/09 05:10 PM

I'd like to keep the duplicated info. Originally we did remove the duplicated fields: id, createdby, etc. However, that made some properties special and could not be updated in the same way - by setting a cmis property field. Also, it became less obvious on how to search on those fields.

I do think an order of processing should be stated: cmis:property is authoritative if present, then atompub (or vice-versa).

The bandwidth cost of having that info in two places is not that significant in my opinion.

[ Permalink | « Hide ]

Al Brown added a comment - 20/Apr/09 01:20 PM

See section 3412, lines 177-205. Update section to add here, repurpose issue to be order of precedence.

[ Permalink | « Hide ]

Ryan McVeigh added a comment - 21/Apr/09 04:58 PM

This proposal looks reasonable. Let's make sure to include a discussion of the atom:id and how it relates to ObjectId. Lines 204-205 specifically need to be updated as they're inaccurate now.