[daisy] Daisy detachment

[Marc Portier]

tim_cranfield at goldenboat.net wrote:
> I would appreciate any feedback on what editing operations the
> detachment program should facilitate.
> 
> Some possibilities:
> 1)Add/edit/delete field
> 2)Add/edit/delete link
> 3)Add/edit/delete customField
> 4)Add/edit/delete Part
> 4)create Document
> 5)create Variant

all of the above would be really nice, my preferred order would be
parts - fields - customfields - links - new docs - new variants

> 
> Some questions:
> -The Document interface does not have a method for adding a field. It
> just has setField(). Why is this?

unsure, I guess fields are part of the document-type so they are there
anyway. they just might have a null value?

Any deeper thoughts to add, Bruno?

> -What is the difference between links and link fields?
> 

fields of type 'link' were recently added, and are probably a more
elegant way for achieving the same (meaning: I can't easily come up with
use cases that would require the previous 'links')

we have to be ready for repositories that still use the older 'links'
though ;-(

Bruno, do you have plans on actually convert the links to link-fields in
some near future release?

> Some considerations:
> -Documents often contain images, which are other Documents. Should these
> be downloaded with the detachment?

As expected, this question re-appears
http://lists.cocoondev.org/pipermail/daisy/2006-May/003947.html
http://lists.cocoondev.org/pipermail/daisy/2006-May/003973.html

and it's not only embedded images (although those are really going to be
hurting) but also attachments, daisy-includes, daisy-query-includes and
simple hrefs...

IMHO the balance between 'enough' and 'absolutely required' is more
subtle then some hard-coded rule can cope with, no?

so the answer of the compulsive neurotic ("when in doubt choose both")
would be:

conceptually
- allow for ddz files to group more then one detached document
- allow for parts in ddz files to have missing related documents

implementation-wise:
- eventually guide the end-user through some wizard maybe that lists the
found references, allows him to list which ones to include
- when preparing the actual part to be edited I assume we should be
doing some link rewriting on the img/@src and a/@hrefs then and let them
point to either the unzipped-included-doc or either a dummy 'sorry not
included' (those could be in the ddz-core.jar and added to the unzipped
ddz directories)


planning wise (suggestion)

- start off with only adding explicit document-id's (in fact; did you
foresee a query-like screen to look those up?) and assume this issue to
be and end-user responsibility
- then add the link-rewriting to the mentioned dummies to kinda mike it
look less broken we he choose to forget some
- then go for (forced) automatic inclusion of the images
- only after that hook that up in some wizard to achieve flexibility
nirvana...


> -Things like branches and languages are stored in a Document object as
> ids. These mean a lot to a computer but not much to a human. It would be
> nice for people to see the name of the document owner, for example, for
> the document they have detached. Retrieving names involves connecting to
> the repository, which is not something we want to do except for when
> downloading and uploading detachments. My solution was to retrieve this
> information when the Document was first downloaded and store it with the
> Document in an implementation of the Document interface called
> DetachmentDocument. This implementation has fields such as ownerName for
> storing this information. Of course this information must be persisted
> in the detachment file so it can be accessed next time the file is
> opened. This means the getXml() method is no longer sufficient as it
> does not provide the name attributes I want. I have the schema and the
> generated classes for a more complete xml rendering, but now I'm
> starting to wonder if it is really so important for people to be able to
> see owner name or branch name since it would be much easier to stick
> with the current implementation. Otherwise, if any one has any
> suggestions or ideas they would be appreciated.

I think having the readable formats will turn out to be highly
appreciated (even a crucial element of perceived usability)

Maybe you should explain why the various 'name' variants can't be in the
getXML()?


-marc= (still catching up)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo at outerthought.org                              mpo at apache.org