Should Open Source Content Management Interoperate?

bergie writes "Advogato is running a thought-provoking article on whether open source content management systems should interoperate. This is a big question involving social issues inside the projects, but also promising huge benefits to developers deploying open source CMSs and to desktop projects like Mozilla, OpenOffice and Xopus wishing to connect with a collaborative backend. This discussion will also be a major topic on the upcoming OSCOM conference."

Comments

Drupal Interops

[quam]

Drupal is an open source content management app run by sites such as DebianPlanet. A couple of examples: if you have a Jabber account, Drupal can authenticate through XML-RPC and through a Jabber server. Also, Drupal allows for utilization of the Blogger API for the posting of content.

Re:Interoperation would be...hard

[md17]

Why can't WebDAV be the standard? From what I have seen WebDAV has a lot of the needed functionaility for a CMS. Jakarta Slide (Open Source Java CMS) is implementing WebDAV as their foundation.

Everything is "content"

[Tablizer]

I cannot comment on the specific articles because even Google cache is slashdotted right now.

Anyhow, the idea that web content, file management, and databases are all different things should perhaps be challenged.

Hierarchical file systems are too rigid IMO, databases charge fat bucks for document management, and web content managers assume that the web world is an island away from other company activities.

I suggest ways be found to combine all these. XML is not the answer because it is linear: you can't "index" by an aspect or relationship not covered in an XML file layout/hierarchy. (If you could, then it would be a database and not an XML file, per se, and nobody has shown that an XML database is better than a document management database or a relational database or whatever. Besides, XML is an exchange format, not really a good storage format.)

Basically, everthing can be reduced to 2 things: "documents" and "attributes". Relational databases do a pretty good job at attribute management [1], but not document management, at least not without addons.

Thus, we need to find a standard protocol for referencing and querying a "big pool of data" based on documents and attributes. Then "content databases" can be built.

[1] There is kind of a mini battle between "defined attributes" and "open-ended" attributes. RDBMS tend to want to know field names in advanced. But it does not have to be that way. But, there are pro's and con's to each approach, defined attributes usually result in better performance, but make it harder to add new fields not anticipated in advanced.