##  Write up pro tools doc

Pro tools has been discussed in terms of cnxml and providing an interface on
publishing to accept cnxml in a completezip type format.

### How does this look from a DMS Point-of-View?

The new DMS desk tool will have a web interface where the following will be true:

-   Provide links to download the `.complete.zip` for any given content.
-   Provide links to download any resources associated with the content (e.g. the PDF).
-   Provide a means to upload a `.complete.zip` for publication,
    which will subsequently provide:
    -   a means to view state and errors
    -   a means to (optionally) preview the content as HTML before submission for publication

The DMS will download a `.complete.zip` of the content.
They will edit/create the portions of the content that are needed.
(It's implied that in order to work on the content they will unzip the file.)
They will then zip up the contents of the work
(a simple tool can be created to do this if necessary,
but right click to 'Archive' should just work).
Lastly, they will upload the edited and archived `.complete.zip` file
to the DMS desk instance.
This upload can either be done as a cli script or via the web interface.


### Why provide an interface to accept cnxml on publishing?

We have cli tools to transform cnxml to html,
so let's use these to compile html and send the payload
as a format publishing already accepts and acknowledges (i.e. internal epub).

1.  Acquire .complete.zip (from zope|publishing)
2.  Work on content
3.  Convert .complete.zip to .internal.epub
4.  Send .internal.epub to publishing (for publication)
5.  Repeat as needed

New development is now scoped to two areas:
a tool to convert a `.complete.zip` to `.internal.epub`
and
an interface on publishing to produce a `.complete.zip`

The external tool is useful in this situation because we can quite litterally
chuck it in to the digital forest when we are done with it.
There it can bitrot and paradise. :)
Also, as a separate tool, others (beyond cnx devs) can maintain it
without having contextual knowledge of other parts of the system.
And another thing,
this does pre-validation of cnxml before submitting it to publishing.

Let's tentatively call this new tool, DMS desk.

Can a DMS run this tool locally?
Sure.
Do they have to run it locally?
No, I think the approach here is to treat this new tool as an editor
similar to cnx-authoring.
It will communicate with cnx-publishing similar to how cnx-authoring does.
In which case it will utilize the same mechanisms for error handling.

The publishing interface to produce a `.complete.zip` file
should be relatively easy. I feel confident that making this small
read-only change will not affect the cnx codebase in adverse ways.
Additionally, the implementation of this interface can be done in two
increments; proxy zope (immediate results) and later actually build the `.complete.zip`.