vtd-xml

Thanks again for clarifying. And yes, I am thinking of the case where Color is a property of many types with no common type ancestor. I don’t really like the idea of creating type inheritance trees for this. And even if I did, most of the CMS products I touch don’t entertain the notion of subtypes (which I don’t really care for) or aspects/mixins (which I would love).

Although it might sound strange to have many content types with common attributes, it seems to happen a lot. Sometimes, we might even have two or more content types with *identical* properties, for example “News” and “Press Release”. Now these should really be the same type but for the quirks of a products that mean you need a different type to apply different workflows, security or other policies. But I digress.

I’m looking forward to seeing 1.0. After receiving comments on this posting, I’ve found so much more to read … I wish I was a vendor so I could try to implement it!

Thanks again,
Jon

If you have many types that have Color, but there is not a common type ancestor that has Color, then best practice would be to create such a type ancestor.

Sometimes adhering to that best practice is problematic. Especially if a system desires multiple inheritance. One of the discussions in CMIS is around mixins/aspects. This is one of the more forward looking proposals. It would allow you to add an aspect, e.g., Colorable, to each class/object instance as appropriate. You could then treat Clorable as a type to search against.

This proposal is being discussed in the TC and John Newton is leading it. It is unclear whether or not it will make it into 1.0.

Just to make sure I’ve got this right, then: I can do “SELECT * FROM Document WHERE ‘green’ = ANY Color” even if Color is not a property of the base type, but is of a few subtypes? I understood from the Search Query Scope Diagram that I could only do the query you suggested if Color was a property of the base type. I presume that “SELECT *” will only return the properties in Document (as each subtype will have different properties).

I do really appreciate someone like yourself that knows CMIS so well answering my questions! I’ll repay with beers any time

Jon

But whereas I agree — and I’d much prefer XPath to SQL — it may not just be a case of it being to hard for the vendors. I think it might also be too hard on many developers. That’s probably why it has seen some, but not great uptake (much the same as XSLT).

So if you want to set a standard that everybody already sort of knows, you go with SQL. Not because it’s the best, or the most appropriate, but because it’ll have the most success, which in the end is pretty important for a standard

I don’t agree that the difference between CMIS and JCR is SQL vs XPath, especially when you consider JCR 2. For me the difference between the two is quite deeper. CMIS is higher level & simpler, it describes protocols (on top of a unique model) and not a language binding, and is supported by more vendors. See the points I made in http://asserttrue.blogspot.com/2009/04/hell-freezes-over-as-big-ecm-vendors.html?showComment=1238880000000#c3031100695560533822

This is a very interesting article. Your choice of search metaphor (XPath vs SQL) is based on where you start your search from. Most ECM systems start search from the point of type. I am looking for a document (invoice, claim, loan, etc) that meets the following criteria. The criteria could be on the properties or its location. It is not necessarily clear that those objects exist in a folder structure. They could. That’s a customer’s choice.

With XPath, you start with a hierarchy. I want to find items under this folder that match a certain criteria. This implies that customers always use the hierarchy and have organized their content that way.

Based on the paradigm you start with, you add in access to the rest of the vendor’s models, such as /root/unfiled hacks. It is probable companies did not implement these extensions the same way as the standard and thus the cost to support increases.

Also, the issue with XPath was since many vendors did not natively support that style, when XPath limitations were encountered (and they were) adding support for XQuery became problematic.

CMIS is based on the idea of standardizing the 80% of what all the vendors do and do well. It is backward looking by design. This decreases the cost and makes it an easier decision on whether to support the effort or not. This was proven by the interoperability plugfest where most vendors created their prototypes with a couple of man-months of effort. That is impressive for a standard that provides significant capability.

I think JCR is a good standard, and a forward looking one, and is the result of a lot of good work by very many talented people. Unfortunately, times change, and a big drawback of a Java standard is typically the lack of MSFT support. SharePoint, like it or not, has an impact on this space and it is important to include them in interoperability.

On your points:
- I still think an XPath query still makes sense for multi-filed documents. Unfiled make slightly less sense. Probably need to hack in some new virtual /root/unfiled/ node.
- I probably wasn’t clear here. My example would be searching across content types such as NEWS_ARTICLE, PRESS_RELEASE or WHITE_PAPER that may have different but overlapping attributes. In your example, is “Document” a reserved work that means all content types? Could I do this in one CSQL query as you have? Or have I misunderstood/misread the spec?
- Agree. I probably shouldn’t have mentioned the breadcrumb notion at all. I mentioned it as it is something that always needs consideration but isn’t really relevant to the discussion at hand.
- I guess I’ve got some more reading to do here too. You know a lot more than I do …

Would you agree, though, that the main difference between CMIS and JCR is SQL v. XPath? Or do you think the other differences are more fundamental?

Thanks again
Jon

It seems to me that XPath is mostly used by XML fans, and is only applicable if you can have a natural mapping of your data into the XML basic infoset. That’s sometimes hard.

Also, have a look at John Newton’s article from 2006 about SQL vs XPath, which is still relevant: http://newton.typepad.com/content/2006/09/sql_vs_xpath_vs.html

Regarding some of the bulleted points you made:
- XPath is more natural for a hierarchy but the hierarchy aspects of CMIS only apply to the folders, the documents themeselves can be multi-filed or unfiled so XPath would have a harder time applying to them,
- If you want to find all documents that are green you can do SELECT * FROM Document WHERE ‘green’ = ANY Color. It’s hard to see a use case where you would want to query at the same times Documents and Folders, or Documents and Relations for instance,
- Folder breadcrumb is an ill-defined notion if you have multi-filing or unfiling, and that’ll be quite common in some CMIS repositories. Anyway you can do getObjectParents to get all the containing folders, then getFolderParent with returnToRoot=true on each,
- Pagination functionality is expressed in the model but may appear differently in the actual protocols, for instance AtomPub specifies RFC 5005 for paging.