Hi,
I present here an alternative method discussed today
for retrieving annotation's position in XWiki source.
When annotating, we got HTML dom tree, so we are
enable to determine path from HTML tree root to
the first and last node concerned by annotation.
I'm considering that is possible for rendering engine
to get for each word his source and position.
So we are enable to request to server a second HTML
dom tree that differs for default rendering by the fact
he wrap each word in a span markup that contains
position of word in xwiki source.
By browsing this last tree using paths introduced
above, we are placed on wrapping span and so are
enable to retrieve offset of first and last word concerned
by annotation.
By this way we don't need a perfect bijection between html
and xwiki syntax. By this way we also don't need to rerender
document.
What about generated words ?
Considering that generated content is atomic, each words
offset equals begin of generating code offset.
1) Do you think it's possible to make such rendering engine ?
Displaying annotations
Only for rendering process, we insert an annotation tag in XWiki
source
in order to retrieve it in HTML and display it nicely using GWT.
A problem appears if we use simple tag as '|' because if annotations
intersect themselves we could lost right couples. My idea
was to group start and end tag using primary key associated
with any annotation object. So we could use this syntax :
{id id}
2) Is this syntax (eventually) compatible with rendering engine ?
Feel free to indicate any other method.
Lucien
Lucien PEREIRA wrote:
I'm sorry, I realized that design document was not clear on this
point. In fact my idea was to do not modify initial xwiki source,
I mean that insertion of the start/end selection tags is only a
way to get the position/length of the selection after mapping from
html to xwiki source.
So after getting it, we model annotation concept by a class stored
independently of the target document. This class stores offset,
length, source concerned, eventually source context and eventually
others.
I think its better to store annotation externally and to not
touch at all to xwiki source because annotation feature musn't
impact neither on the default XWiki rendering process (annotation
rendering should be done by an additional piece of code in client side)
nor on the XWiki synthax.
I agree with ludovic's general process description.
Lucien
Marius Dumitru Florea wrote:
Ludovic Dubost wrote:
Hi,
The solution we are trying to find for annotation is one that would not
necessarly require to store permanently the annotation in the document.
We could decide to do this and it's true that it can remove us a few
problems.
But one of the idea was to try to be non obtrusive and do not touch the
annotated document when annotating. This would also allow to use the
same annotation tool on non wiki content (static HTML or even any
document transformable to HTML as long as it would not change).
Now even tough we decide or not to store the annotation fully /
partially (only the marker, and keep the annotation itself outside) /
not at all in the wiki syntax document, I think the same technologies
could be used or not to do the annotation itself.
Example:
wiki syntax document with annotation in wiki macro (whatever it is)
or
wiki syntax document with annotation externally with positions in the
document
-->
transformed to wiki syntax with annotation
-->
transformed to HTML with HMTL markers for the annotation which willl
allow a JS interface to make great and fun UI to visualize the annotation
----
insert of new annoation in the same HTML as the one generated by the
wiki syntax rendering of annotation
-->
transformation to wiki syntax with wiki macro for the new annoation
-->
save of the wiki syntax document + annoation
or
extraction of the annotation to calculate it's position
For repositionning the annotation on document changes, we would have
nothing to do in case of the marker stored in the wiki syntax or we
would have to work on DIFFs to reposition the annotation. This could be
done by reintroducing the marker and see how they move after the
merging. If there is a conflict then this means the impact on the
annotation is significant (disappearance of content or significant
change). With a DIFF at the character level I think conflict will
automatically mean disappearance of content.
Now we could decide to not make the effort of trying to store
annotations separately and to decide to have at least the markers in the
wiki document. Now if we do this we need to be aware that this could
make annotation create a lot of updates to document.
This is a simple decision to make:
1/ Annotation with markers in the wiki document
- no need for repositioning but issue if annotation markers are
removed by editing
- slightly simpler to set an annotation since it is like and editing
but this creates saving of document after conversion from HTML to wiki
syntax (risk on document)
- much easier to render annotation, harder to not render them
- could create heavy document
- one would need the edit right on the document to be able to annotate.
1/ Annotation with markers
- more work to position
- more work to set the annotation but no risk on the document
- slightly more work to render annotation
- lighter document
- annotation system can be more easily used on non wiki content
I'm more into external annotations. This way they could be tied to my
profile, where I could specify if I want them public or not -- just an idea.
Marius
Ludovic
Vincent Massol a écrit :
Hi Lucien and all,
Several ideas:
1) If this were implemented at the xwiki syntax level we couldn't do
it with a macro as this would break the semantic of the wiki but it
could be done using semantic inline poroperties ([
1]http://code.google.com/p/wi
kimodel/wiki/AdvancedStructuralElements
). Note that we haven't implemented this yet in the rendering. Right
now the closest would be using custom XHTML attributes.
2) If it were to be implemented at the level of the wiki syntax it
would only work with XWiki syntax 2.0 since we don't have a XHTML to
wiki syntax converter for the 1.0 syntax (there would be too many
other problems too)
3) You must talk to Marius and reuse his Range and Selection API that
he implemented for Firefox/IE for selecting portions of text
4) I agree that it would be easier implemented at the xwiki syntax as
otherwise you would have a very hard time synchronizing document
changes with text selections. In addition having it at the wiki syntax
allows to enter annotations when editing the document using the
wysiwyg editor or the wiki editor and it solves the way to persist the
location information.
So, is 2) acceptable for your need Lucien?
If we agree that it's best to implement at the wiki syntax level then
we'll need to wait for 1.8 since we'll need to introduce semantic
properties in the rendering module.
This is an interesting use case ;)
Thanks
-Vincent
On Nov 17, 2008, at 10:22 AM, Lucien PEREIRA wrote:
Hi,
I'd like to propose this design
[
2]<http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature> for
annotation feature implementation.
Vote is about choosing between solution 1 and 2.
if we can have an (almost) perfect bijective function between HTML and
XWiki code, I'm +1 for solution 2 because implementation will be more
efficient , stable and clean.
Otherwise solution 1 seems to be a good solution.
WDYT?
Lucien
_______________________________________________
devs mailing list
[3]devs(a)xwiki.org
[
4]http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[5]devs(a)xwiki.org
[
6]http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[7]devs(a)xwiki.org
[
8]http://lists.xwiki.org/mailman/listinfo/devs
References
1.
http://code.google.com/p/wikimodel/wiki/AdvancedStructuralElements
2.
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature
3. mailto:devs@xwiki.org
4.
http://lists.xwiki.org/mailman/listinfo/devs
5. mailto:devs@xwiki.org
6.
http://lists.xwiki.org/mailman/listinfo/devs
7. mailto:devs@xwiki.org
8.
http://lists.xwiki.org/mailman/listinfo/devs