Separating out Metadata
Document Actions
Why?
As I mentioned in a reply to Chuck, we don't often talk about the motivation for this move, so I'll try to lay it out some of the reasons here:
- To simplify editing: Depending on who you talk to, CNXML
markup isn't all that bad but looking at the large block of XMLish
metadata is intimidating if you aren't comfortable with it. We
have (hopefully) easy-to-use forms for metadata editing and we
encourage (read: require) our authors to use those for changing
metadata. They get confused when they try to edit it in the XML and it doesn't work.
- To allow for separate development: As long as both metadata and CNXML live in the same file, they must be validated together. This pretty much requires lockstep development of both. By separating the two we can allow each to proceed at its own rate. We can even swap out metadata formats entirely and move to something like Dublin Core or IMS.
For people who want it as a single XML file we can stuff the metadata in for exporting and pull it apart again on import.
How?
I've outlined the migration
as a two-step process. First pulling the XML out of the
user-visible side, and second the separate storage. For the
first-phase my plan was to remove the <metadata> tags upon module
checkout. I orginally thought about doing that with regular
expressions the way we're currently doing our get/setMetadata
functions. But then I'd have to write a new expression for
inserting the metadata back in during publication. I didn't
want to do that, and besides, there was a better way. For our
enhanced edit-in-place Adan and I had already created
{add,delete,replace}Node methods that did XPath manipulations on
a document tree. This seemed like a natural fit, and sure enough
it works. It only took me half a day or so to get it running and
most of that was mainly due to me forgetting that you can't free
removed
namespace nodes until after the document has been reconciled. But
that's a whole other story for a different day.
Re: Separating out Metadata
