Content management changes to simplify collaboration
Ilya Haykinson
haykinson at gmail.com
Tue May 18 17:13:30 UTC 2010
All,
I would like to jump-start the discussion of the content management system
(i.e. content pool), below.
Here are my values for this type of a system:
- structured data storage with a concept of a "unit of content"
- this is the smallest "addressable" item
- I propose that the units of content be paragraphs of copy
- hierarchical content organization that organizes the content units
- ability to create "works" that combine content units in a different
organizational structure
- full-text search capability
- data storage using semantic markup
- data input using either plain text, or the semantic markup
- simple user account management
- ability to either instantly commit (for authenticated users) or queue up
changes for review (for anonymous users)
- ability to process a review queue
- audits of all changesets
Assuming agreement on the above (not a given, but I wanted to explore
further), there are some open questions with this approach:
- What data format should we use for storage?
- What should be the backing store for this data?
- What technology should be used to implement this?
Candidates for storage:
- DocBook
- Pro: strong in semantics; lots of tools
- Cons: complex to write manually
- Mallard
- Pro: simpler than Docbook
- Cons: weaker semantics; fewer tools
Of these, my preference would be for DocBook -- mainly for its
comprehensiveness in markup capabilities, and because we could always
convert to Mallard from it (but not the other way).
Candidates for backing store:
- Database
- Pros: we can design whatever storage structure we want; easier to
search or query; can store metadata alongside data; could work well with
review queues
- Cons: we'd have to build an RCS-style system within a DB; harder to
contribute offline (can't check out the whole corpus)
- RCS like bazaar or git
- Pros: already-built RCS; strong support for changesets; able to check
out whole corpus and work offline; easier to write file-based tools
- Cons: poor storage of metadata; poor query ability
I don't have a strong recommendation here. Due to the difficulty of storing
metadata in an RCS I could see going with a database-only system (and taking
the hit on implementing an RCS-lite); or going with a hybrid where all the
metadata and the latest version is in a database but revisions etc are
stored in an RCS.
I would leave the technology question for some future date.
Thoughts? Feedback?
-ilya haykinson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20100518/1b6af774/attachment.html>
More information about the ubuntu-doc
mailing list