>> How does Vade Mecum make annotions in the first place? Can you
>> do this on the PDA, does it need to happen before hotsync?
> I think the only current way is to create them on the PDA. There doesn't
> appear to be any conduit, etc., for pulling the annotations off the PDA
> either.
Does PocketPC have a way to back up (or beam) generic databases?
Is there any way to every share these notes?
But as long as editing on the PDA is an option (and I agree that it
should be) then some type of editing is needed. To me, the obvious
solution is to put some editing functions into plucker, but I'm not
the one who would do that in the near future. (And those who might
have objected to any on-PDA changes.)
Another option is to use a different program to create annotations.
These probably won't be in exactly the same format as Vade Mecum
unless someone writes a custom editor (and then why not put it in
Plucker). It would probably be either text (like memopad) or doc.
Plucker should be able to read both of those, but getting it to
recognize links would be harder, to the point where it might be
easier to just do the editing in plucker.
>> I think it might make more sense to allow inter-document links
> Through a new function code which references the unique ID
> generated from the docName, record ID, and paragraph offset
> (+ char offset?) of the destination pdb?
Since we need the docName, we probably can't just reuse the
bookmark format. If we're using a new function, we should
probably make it more general, so that it can call any other
program with arbitrary input -- but calls to plucker will be
understood correctly. (Alex discussed this recently enough
that he might be willing.)
There is still a question of whether the target document should
have some sort of alert ("Go fetch an annotation!") or we should
rely on the reader to just track annotations on its own. Making
the reader do the work is a bit slower and more memory intensive,
but probably more robust.
> How would you specify this kind of a link in your source html?
The general rule is:
protocol://host:port/path;parameter?query#fragment
Some specs let you put parameters in more places than that, but
almost no one uses the parameter in real life, so I'm not sure
how safe it really is.
In our case, I think url#fragment will get us close, but we'll
have to use a parameter to specify individual characters, unless
we edit the original document.
This definately ties in with Alex's Exact Anchor suggestion --
was there a decision on that yet? If we use an exact anchor
with a range target (instead of a point target), that would
work.
For the source html, my first assumption would be that parameter
would be the number of characters after the nearest preceding
anchor, then the length.
maindoc;33;78#sec3
would indicate that it starts 33 characters after the sec3
target anchor, and goes for 78 characters.
I welcome other suggestions, because:
(1) This is ugly
(2) I don't like putting the parameters before the fragment, even
though they're smaller.
(3) It isn't clear that the second number should be a length instead
of another offset.
(4) It isn't clear that the offset should start from an anchor,
instead of a paragraph start or even the document start.
(5) Not all documents have internal anchors, so you might have to
count from the beginning anyhow. If so, should we allow xpath
type specs to get closer? (For instance, could you say
"go to the fourth div, then the second paragraph within that, then
the first span within that" even if the anchors aren't named?
(6) Counting characters is ugly enough that it still really requires
tool support, particularly if some characters "don't count". For
instance, what numbers should be used with:
"123 <tag1 attr="val"> target starts <tag2> </tag2> target end </tag1>"
(Normally, you would strip out the tags and attributes, and collapse
whitespace - but there might still be two spaces between "123" and
"target" because there is a tag in between.)
>> in general (possibly with this as a special case), and to allow
>> at least minor editing in general if we put the functionality
>> in for notes. (If we don't put it in, then I suppose you can
>> already edit the source on your desktop.)
> Do I understand that you are referring to the annotations
> themselves being Plucker documents?
They have to be something. The current Vade Mecum format already
requires a special editor (or a very careful user) to get the
numbers right. If we're writing an editor, it makes sense to me
that it should edit a plucker document, but ... others might
disagree.
> It would be sweet to have multiple annotation databases per pdb
> as well. In the context of Pluckerbooks, it would be ideal to
> distribute commentaries in this way. Footnotes as well.
I agree, but this is harder, as we can't just look for a certain
database name anymore. Perhaps we could add a list of commentaries
to the current metadata file? What happens if a base file is
deleted or beamed? Should the commentaries also be deleted/beamed?
-jJ
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
