| Thinking about it more... There is not much need for XML. The inputs are plaintext replies (or HTML formatted as plaintext). The original document is immutable. There is no state (because it can be collated from scratch every time). EDIT: If updates are allowed in any non-email based way (e.g., via a BUI, REST APIs) then email must be generated and sent so that all the state is in the email archives and all participants can collate the same state. But the result of the collation is more like a database and less like a document. In particular there's not much need for marking up commentary. Multiple collation output formats will be needed: plain text, XML, XHTML, JSON. These formats/schemas are only needed for display purposes, not interchange, as the collation results can be computed independently by all who have access to the emails. This means there is nothing to standardize! Thus collation state can be kept any way you want. XML, SQLite3, some NoSQL, any in-memory representation you like -- whatever suits you. Still, I'd use anything that has a nice, declarative query language. XML (XSLT/XPath), JSON (JSONPath, jq), or an RDBMS (SQL) -- all will do. For you, and given your emphasis on open source, SQLite3 or PostgreSQL will work best, I think. You can generate all of the output formats you need from such a database. |