Hi Shane, the changes you suggest make a lot of sense to me, the format would be much easier to parse and evolve in the future I think (I do not have enough understanding of the spec to judge the overall impact, though).
One minor thing I thought about the last example - how about this: <cmis:repositoryInfo> <cmis:properties> ... </cmis:properties> <cmis:capabilities> ... </cmis:capabilities> <cmis:changes> <cmis:change name="includeDocuments">true|false</cmis:change> <cmis:change name="includeFolders">true|false</cmis:change> </cmis:changes> </cmis:repositoryInfo> br Michael On Tue, May 12, 2009 at 11:51 PM, Shane Johnson <[email protected]>wrote: > Hi Everyone, > > I have a few thoughts regarding the CMIS specification that came about > while working on unit tests. Right now I'm just focusing on the repository > info. > > <cmis:repositoryInfo> > <cmis:repositoryId>repid1</cmis:repositoryId> > <cmis:repositoryName>Repository1</cmis:repositoryName> > <cmis:repositoryRelationship>self</cmis:repositoryRelationship> > ... > <cmis:capabilities> > <cmis:capabilityMultifiling>true</cmis:capabilityMultifiling> > <cmis:capabilityUnfiling>true</cmis:capabilityUnfiling> > > > <cmis:capabilityVersionSpecificFiling>true</cmis:capabilityVersionSpecificFiling> > ... > <cmis:capabilityChanges>includeDocuments</cmis:capabilityChanges> > <cmis:capabilityChanges>includeFolders</cmis:capabilityChanges> > <cmis:capabilityChanges>includeRelationships</cmis:capabilityChanges> > ... > <cmis:changesIncomplete>true</cmis:changesIncomplete> > </cmis:capabilities> > <cmis:cmisVersionSupported>0.61</cmis:cmisVersionSupported> > </cmis:repositoryInfo> > > From a purely client perspective this is a little awkward. > > This first issue is mixing properties and capabilities. This requires a > little more than it should because the properties are simple while > capabilities is complex element. Perhaps something like this. > > <cmis:repositoryInfo> > <cmis:properties> > <cmis:property name="repositoryId">repid1</cmis:property> > <cmis:property name="repositoryName">Repository1</cmis:property> > <cmis:property name="repositoryRelationship">self</cmis:property> > ... > </cmis:properties> > <cmis:capabilities> > <cmis:capability name="Multifiling">true</cmis:capability> > <cmis:capability name="Unfiling">true</cmis:capability> > <cmis:capability name="VersionSpecificFiling">true</cmis:capability> > ... > </cmis:capabilities> > </cmis:repositoryInfo> > > Of course I don't mind if the element names stay the same > (<cmis:repositoryId/>). It just seems like it is less flexible and more > difficult to marshal/unmarshal. > > The second issue is the changes capability. It would be nice if this was > either a multi valued element, separate of the simple capabilities, or > turned into individual properties. > > > <cmis:capabilityChangesIncludeDocuments>true|false</cmis:capabilityChangesIncludeDocuments> > > <cmis:capabilityChangesIncludeFolders>true|false</cmis:capabilityChangesIncludeFolders> > > - or - > > <cmis:capabilityChanges> > <cmis:includeDocuments>true|false</cmis:includeDocuments> > <cmis:iIncludeFolders>true|false</cmis:iIncludeFolders> > </cmis:capabilityChanges> > > - or - > > <cmis:capabilityChanges>includeDocuments, > includeFoldes</cmis:capabilityChanges> > > - or - > > <cmis:repositoryInfo> > <cmis:properties> > ... > </cmis:properties> > <cmis:capabilities> > ... > </cmis:capabilities> > <cmis:changes> > <cmis:includeDocuments>true|false</cmis:includeDocuments> > <cmis:iIncludeFolders>true|false</cmis:iIncludeFolders> > </cmis:changes> > </cmis:repositoryInfo> > > > None of these things are that big of a deal it is just that I find myself > writing unnecessary code in order to handle them. I figure most of the > people on the list are actively involved in the spec and I'd be interested > in any thoughts you guys have to share. > > Thanks, > Shane > -- Michael Marth | http://dev.day.com/
