A Start on Document Management

I just added attached_node.module to the CVS repository.

There hasn't been much movement with document management lately from what I can tell. I've been working on it for quite a long time, and have changed my angle on it a few times by now. From the README:

Some code lifted from other modules, including image.module.

Purpose of this module:

Allow users to refer to other nodes from within the body or teaser of a node.
Provide a somewhat standard means of formatting the link to such nodes.
Allow user to customize position and attributes of this link/reference.

This is implemented for the most part as an output filter.

The most popular use case for document management in this crowd seems to be
attaching images to stories and blog entries. Arguments have gone round and
round about what is the best way to do this, and in the process of trying to
figure out what will make the most people happy, I have come to a compromise.

I originally designed a relational database model for managing attached nodes
and all of the maintenance code that goes with it. After much thought, and
coming across the filter that the image module uses, it occurred to me that
perhapse the best solution was the simplest one: use meta tags.

I took the concept that the image module used for tag format and made it a bit
more generalized. The format currently is of the form:

[node:NID, align="center", height="50", title="look at this stupid article"]

..where NID is the node id of the node being linked to, and all of the optional
parameters are specific to whatever type of node is being linked to.

Image nodes, for instance, would display a thumbnail in this tag's place (similar
to how the [image:NID..] tag works with the image.module. Each node's allowed
parameters are specified on the filter admin page. You can allow your users to
override whatever node properties you would like. Some don't make sense (like nid)
so caveat emptor, but nothing gets overwritten unless you explicitly set up
permissions to do so. Additionally, these properties are only overwritten for
the purposes of displaying the node. Nothing is saved to the database.

The tricky part doesn't exist yet. On each form edit page, there should be a
link to "attach node". This should pop up the "Create Content" (node/add) page.
Along with this page will be the understanding that whatever node gets created
will eventually be referenced from the original node. This can be done several
ways and I have not decided yet how exactly this will be done.

1. Form Keys:
The original node (parent) will have a form key generated. Children nodes
will need to maintain this key until they are saved. The form key gets placed
in a table awaiting the parent to be saved. When the parent is saved, meta
tags from all children are appended. This could be done at the preview phase
as well.

2. Java script:
Upon saving a child node, the node body form element of the parent will have
a meta tag referring to the child appended to it. This will allow the user
to immediately customize the position and attributes of the attachment.

There are other techniques, but these are the two that I'm most considering.

Ideas? Opinions?