[daisy] Daisy Detachment - updates

[Bruno Dumon]

On Wed, 2006-08-02 at 21:58 -0400, tim_cranfield at goldenboat.net wrote:
> Recently I have been working on the following things:
> 
> 1)Implementing the uploading of edited documents to a 
> repository.
> 
> Reading some of the comments about daisy 2.0, I imagine you 
> want the ability to upload to a different repository to which 
> it was retrieved from. Actually at the moment I am not storing 
> the repository a Document belongs to. You have to choose a 
> repository to connect to before you can upload.

It's good to see you're following up on Daisy 2.0. I'm not sure if you
should start looking at actually using it though, as it might complicate
things for you [because it might be occasionally unstable, and the
db-schema might change from time to time], but if you want, sure do.

For the detachments (or any Daisy-client application), the main thing
that will change is that a document ID will no longer be a number (like
99) but a string (like 99-TADA). However, that doesn't mean the client
needs to worry about namespaces, the client can simply treat it as an
opaque string used to identify a document. So, except for changing a
long to a string, nothing changes.

Regarding not storing the repository in the detachment: actually, I
think you should store the repository, especially with Daisy 1.5. The
meaning of a document ID like '99' will be different in two different
repositories: they will represent different documents.

> 
> Although I have been using the 1.5 jars, I think the 
> Detachment project will fit better with 2.0, as that will 
> allow for the creation of Documents offline, and for 
> transferral between repositories. It raises the issue of what 
> namespace to use for a Document created by the Detachment 
> program however.

I'm not sure how Daisy 2.0 makes the creation of documents offline
different. You could of course assign each detachment client a different
namespace, in which it can number documents, so that it can itself make
up the IDs of new documents. However, I'm not sure this is a good idea
(this might require lots of namespaces, one for each client, and this
would work against the goal of keeping the namespaces readable,
recognizable names).

Where there would be room for co-operation is in the format used by the
export/import tools, described at:
http://cocoondev.org/daisydocs-2_0/impexp/332.html

This format has been designed to be simple, and is independent from the
XML format used by the repository server. It uses names everywhere
instead of IDs (for field/part/document types, for collections, etc,
except for the document IDs of course).

The format doesn't allow to define documents that have no ID assigned
yet, though.

There's also a set of classes (in
org.outerj.daisy.tools.importexport.model) that are basically 'value
objects' for documents and schema types. The reason for introducing
these was so that the imp/exp tools don't have to work with the XML
directly (less important), and especially to allow changing the content
of the documents and schema when importing/exporting. Anyhow, these
classes *might* be useful also for a detachment client. I havn't really
thought about it deeply though.

Since you're already quite far in your project, I wouldn't let you
divert by any of this work, and continue as you are.

> 
> 2)Adding and editing CustomFields, Fields and Links. Regarding 
> Fields - is there a set ID for each type - string, long etc ? 
> If I add a new Field I need to know what ID to give it.

If with ID you mean the field type ID, then nope, as there can be many
different string, date, etc. fields.

I'd need to have a look at what you've done in this area, but I'd assume
you store a copy of the document type(s) used by the documents in the
detachment? Or maybe even of the complete repository schema, as you
can't really know on beforehand what new types of a documents a user
would want to create.

> 
> 3)Automatically including image Documents with a Document 
> chosen for downloading. This is done with Bruno's code for 
> extracting image links:
> http://lists.cocoondev.org/pipermail/daisy/2006-July/004572.html
> The DaisyHtml part data is run through a SAX processor to get 
> the img links.
> 
> Perhaps including images couold be optional.
> 
> 4)Now I am considering how to change the DaisyHtml into normal 
> Html that can be read by an editor. In particular:
> -img src attributes have to be changed
> -css link has to be inserted
> -must be UTF-8 encoded 
> (http://lists.cocoondev.org/pipermail/daisy/2006-June/004037.html)
> 
> My basic idea is to create a second html file which can be 
> used for editing, through xsl, SAX or DOM.

and then afterwards, be converted back again?

What we do for the HTML editor in the Daisy Wiki, is storing the
original image source (daisy:something) in a special attribute
('daisy-src'), and then set the real src attribute to something the
editor/browser recognizes. You could probably use a similar approach
(assuming the launched external editors don't remove the daisy-src
attribute). When including the html in the detachment again, you can
then set the src again to daisy-src, and remove the daisy-src attribute.
And you could also check if the src points to a new image, not yet in
the detachment, and automatically add an image document to the
detachment for that.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org