[xwiki-devs] [Discussion] Annotations feature current state and roadmap
Hello devs, The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing). Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration. I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles. *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default *Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation. What do you think? For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal. Thanks (for reading this very long mail), Anca
Hi Anca, On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <[email protected]>wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the following: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner.
I'm not sure I understand this one well. What exactly do you mean by "different types of annotations"? From what I understand right now, this means the following: 1. I select text and choose to annotate it 2. I select custom properties for my annotation (let's say additional "city" & "country" fields) 3. I fill in those fields and save the annotation 4. My annotation is saved with those custom fields If this is correct, I'm a bit afraid this will bring un-needed complexity both to the UI and the backend implementation. From what I understood so far it looks a bit like having the XClass editor each time ones creates a new annotation -> isn't that overkill? An alternative solution I was thinking about was to use only 1 field with a semantic syntax & autosuggest (something like: @city:Paris @country:France). Is that a possible option? Or maybe it doesn't make sense in the context or your work? Yet another option would be to offer a number of already configured types to select from in a list when adding a new annotation.
* be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
Sounds good. I would like to propose the following road to perfect this feature:
*Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE
Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
- ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Plugin or component? (maybe this is the same thing under a different name) *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next
year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.)
My personal point of view is that being able to annotate any part of a XWiki document is more important than being able to configure the type of annotation to add. Is there a hard requirement on the order from the Scribo research project on this?
* integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
I guess that will depend on its quality by this time. I think it would be a great addition to XE's default feature set. *Version 1.2* (future)
* finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
I think this can become a key differentiating feature of XWiki since I'm not aware of any wiki that has them implemented yet. MS Word's annotation system is widely used and I think XWiki annotation would resonate positively with XWiki users coming from such text editors. For the moment I will focus on version 1's tasks while finding a good
architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail),
:-) Guillaume
Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Guillaume, Guillaume Lerouge wrote:
Hi Anca,
On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <[email protected]>wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the following: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner.
I'm not sure I understand this one well. What exactly do you mean by "different types of annotations"? From what I understand right now, this means the following:
1. I select text and choose to annotate it 2. I select custom properties for my annotation (let's say additional "city" & "country" fields) 3. I fill in those fields and save the annotation 4. My annotation is saved with those custom fields
If this is correct, I'm a bit afraid this will bring un-needed complexity both to the UI and the backend implementation. From what I understood so far it looks a bit like having the XClass editor each time ones creates a new annotation -> isn't that overkill?
An alternative solution I was thinking about was to use only 1 field with a semantic syntax & autosuggest (something like: @city:Paris @country:France). Is that a possible option? Or maybe it doesn't make sense in the context or your work?
Yet another option would be to offer a number of already configured types to select from in a list when adding a new annotation.
Not exactly. The idea was that an admin or a wiki programmer could configure the annotation application (such as setting an XWiki class as the annotation type) and then whenever a user adds an annotation, he will get, in the annotation "bubble", a form to edit an object from that class. Right now, to do that, you'd need to write a few java components & rewrite the js client. The idea is to have that easily configurable, "scriptable" from the wiki.
* be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
Sounds good.
I would like to propose the following road to perfect this feature:
*Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE
Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
I don't have a plan.
- ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Plugin or component? (maybe this is the same thing under a different name)
Application with server side code, I don't know exactly how this would be called.
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next
year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.)
My personal point of view is that being able to annotate any part of a XWiki document is more important than being able to configure the type of annotation to add. Is there a hard requirement on the order from the Scribo research project on this?
No, it's not atm afaik, although Scribo could be implemented like that (Scribo annotations are structured, not only a piece of text, even if "serializable" as a text). Actually this point is supposed to be an iteration in both directions (not only about typed annotations leaving behind the second requirement), and for the annotation target I specified:
and one should easily set a field in a structured document which would support annotations.
* integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
I guess that will depend on its quality by this time. I think it would be a great addition to XE's default feature set.
*Version 1.2* (future)
* finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
I think this can become a key differentiating feature of XWiki since I'm not aware of any wiki that has them implemented yet. MS Word's annotation system is widely used and I think XWiki annotation would resonate positively with XWiki users coming from such text editors.
For the moment I will focus on version 1's tasks while finding a good
architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail),
:-)
Thanks, Anca
Guillaume
Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Anca, On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca <[email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Anca,
On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <[email protected] wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the following: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner.
I'm not sure I understand this one well. What exactly do you mean by "different types of annotations"? From what I understand right now, this means the following:
1. I select text and choose to annotate it 2. I select custom properties for my annotation (let's say additional "city" & "country" fields) 3. I fill in those fields and save the annotation 4. My annotation is saved with those custom fields
If this is correct, I'm a bit afraid this will bring un-needed complexity both to the UI and the backend implementation. From what I understood so far it looks a bit like having the XClass editor each time ones creates a new annotation -> isn't that overkill?
An alternative solution I was thinking about was to use only 1 field with a semantic syntax & autosuggest (something like: @city:Paris @country:France). Is that a possible option? Or maybe it doesn't make sense in the context or your work?
Yet another option would be to offer a number of already configured types to select from in a list when adding a new annotation.
Not exactly. The idea was that an admin or a wiki programmer could configure the annotation application (such as setting an XWiki class as the annotation type) and then whenever a user adds an annotation, he will get, in the annotation "bubble", a form to edit an object from that class. Right now, to do that, you'd need to write a few java components & rewrite the js client. The idea is to have that easily configurable, "scriptable" from the wiki.
Ok, thanks for the clarification :-) Sounds good to me since it's not too complex for users but at the same time addresses Scribo's needs (if I understood those correctly).
* be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
Sounds good.
I would like to propose the following road to perfect this feature:
*Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE
Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
I don't have a plan.
Good luck.
- ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Plugin or component? (maybe this is the same thing under a different name)
Application with server side code, I don't know exactly how this would be called.
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
next
year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.)
My personal point of view is that being able to annotate any part of a XWiki document is more important than being able to configure the type of annotation to add. Is there a hard requirement on the order from the Scribo research project on this?
No, it's not atm afaik, although Scribo could be implemented like that (Scribo annotations are structured, not only a piece of text, even if "serializable" as a text).
Actually this point is supposed to be an iteration in both directions (not only about typed annotations leaving behind the second requirement), and for the annotation target I specified
and one should easily set a field in a structured document which would support annotations.
Ok. Sounds good given your above explanation about annotation definition in a XClass. Guillaume
* integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
I guess that will depend on its quality by this time. I think it would be a great addition to XE's default feature set.
*Version 1.2* (future)
* finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
I think this can become a key differentiating feature of XWiki since I'm not aware of any wiki that has them implemented yet. MS Word's annotation system is widely used and I think XWiki annotation would resonate positively with XWiki users coming from such text editors.
For the moment I will focus on version 1's tasks while finding a good
architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail),
:-)
Thanks, Anca
Guillaume
Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
Hi Anca,
On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Anca,
On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca<[email protected] wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the following: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner.
I'm not sure I understand this one well. What exactly do you mean by "different types of annotations"? From what I understand right now, this means the following:
1. I select text and choose to annotate it 2. I select custom properties for my annotation (let's say additional "city"& "country" fields) 3. I fill in those fields and save the annotation 4. My annotation is saved with those custom fields
If this is correct, I'm a bit afraid this will bring un-needed complexity both to the UI and the backend implementation. From what I understood so far it looks a bit like having the XClass editor each time ones creates a new annotation -> isn't that overkill?
An alternative solution I was thinking about was to use only 1 field with a semantic syntax& autosuggest (something like: @city:Paris @country:France). Is that a possible option? Or maybe it doesn't make sense in the context or your work?
Yet another option would be to offer a number of already configured types to select from in a list when adding a new annotation.
Not exactly. The idea was that an admin or a wiki programmer could configure the annotation application (such as setting an XWiki class as the annotation type) and then whenever a user adds an annotation, he will get, in the annotation "bubble", a form to edit an object from that class. Right now, to do that, you'd need to write a few java components& rewrite the js client. The idea is to have that easily configurable, "scriptable" from the wiki.
Ok, thanks for the clarification :-)
Sounds good to me since it's not too complex for users but at the same time addresses Scribo's needs (if I understood those correctly).
Well, users shouldn't really be aware of the fact that the annotation type if flexible, they should get a nice form allowing them to fill in data about an annotation. This annotation typing should allow programmers to set up their wiki-specific types. Anca
* be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
Sounds good.
I would like to propose the following road to perfect this feature:
*Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE
Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
I don't have a plan.
Good luck.
The only problem with GWT is that the javascript is not editable right away: it goes through compilation (so the source itself is not the "executable" anymore, as in standard interpreted languages which js is) whereas a jsx, for example, is editable from the wiki. Again, an admin / programmer in a wiki could go in and tweak some js without access to the server fs, or a GWT compiler, or downloading sources, or etc. However, the main advantage of GWT is its cross-browser-ness, the precious selection API we have and easy development in the more "stable" Java. I don't have a clear opinion about this yet, WDYT? Thanks, Anca
- ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Plugin or component? (maybe this is the same thing under a different name)
Application with server side code, I don't know exactly how this would be called.
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
next
year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.)
My personal point of view is that being able to annotate any part of a XWiki document is more important than being able to configure the type of annotation to add. Is there a hard requirement on the order from the Scribo research project on this?
No, it's not atm afaik, although Scribo could be implemented like that (Scribo annotations are structured, not only a piece of text, even if "serializable" as a text).
Actually this point is supposed to be an iteration in both directions (not only about typed annotations leaving behind the second requirement), and for the annotation target I specified
and one should easily set a field in a structured document which would support annotations.
Ok. Sounds good given your above explanation about annotation definition in a XClass.
Guillaume
* integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
I guess that will depend on its quality by this time. I think it would be a great addition to XE's default feature set.
*Version 1.2* (future)
* finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
I think this can become a key differentiating feature of XWiki since I'm not aware of any wiki that has them implemented yet. MS Word's annotation system is widely used and I think XWiki annotation would resonate positively with XWiki users coming from such text editors.
For the moment I will focus on version 1's tasks while finding a good
architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail),
:-)
Thanks, Anca
Guillaume
Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Anca, On Fri, Oct 16, 2009 at 10:54 AM, Anca Luca <[email protected]>wrote:
On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
Hi Anca,
On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Anca,
On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca<[email protected] wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the following: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner.
I'm not sure I understand this one well. What exactly do you mean by "different types of annotations"? From what I understand right now, this means the following:
1. I select text and choose to annotate it 2. I select custom properties for my annotation (let's say additional "city"& "country" fields) 3. I fill in those fields and save the annotation 4. My annotation is saved with those custom fields
If this is correct, I'm a bit afraid this will bring un-needed complexity both to the UI and the backend implementation. From what I understood so far it looks a bit like having the XClass editor each time ones creates a new annotation -> isn't that overkill?
An alternative solution I was thinking about was to use only 1 field with a semantic syntax& autosuggest (something like: @city:Paris @country:France). Is that a possible option? Or maybe it doesn't make sense in the context or your work?
Yet another option would be to offer a number of already configured types to select from in a list when adding a new annotation.
Not exactly. The idea was that an admin or a wiki programmer could configure the annotation application (such as setting an XWiki class as the annotation type) and then whenever a user adds an annotation, he will get, in the annotation "bubble", a form to edit an object from that class. Right now, to do that, you'd need to write a few java components& rewrite the js client. The idea is to have that easily configurable, "scriptable" from the wiki.
Ok, thanks for the clarification :-)
Sounds good to me since it's not too complex for users but at the same time addresses Scribo's needs (if I understood those correctly).
Well, users shouldn't really be aware of the fact that the annotation type if flexible, they should get a nice form allowing them to fill in data about an annotation. This annotation typing should allow programmers to set up their wiki-specific types.
Anca
* be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
Sounds good.
I would like to propose the following road to perfect this feature:
*Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on
a
regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE
Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
I don't have a plan.
Good luck.
The only problem with GWT is that the javascript is not editable right away: it goes through compilation (so the source itself is not the "executable" anymore, as in standard interpreted languages which js is) whereas a jsx, for example, is editable from the wiki. Again, an admin / programmer in a wiki could go in and tweak some js without access to the server fs, or a GWT compiler, or downloading sources, or etc.
However, the main advantage of GWT is its cross-browser-ness, the precious selection API we have and easy development in the more "stable" Java.
Is there a way to have GWT retrieve values for some CSS properties from XObjects? For instance, is the GWT-based UI could retrieve its CSS color codes from a ColorTheme object it would allow you to code in GWT while still giving the wiki admin some control over the annotations' look. Is that doable? Guillaume I don't have a clear opinion about this yet,
WDYT?
Thanks, Anca
- ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an
installable
plugin but not included by default in XE, unless after a few bugfixing cycles.
Plugin or component? (maybe this is the same thing under a different name)
Application with server side code, I don't know exactly how this would be called.
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
next
year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.)
My personal point of view is that being able to annotate any part of a XWiki document is more important than being able to configure the type of annotation to add. Is there a hard requirement on the order from the Scribo research project on this?
No, it's not atm afaik, although Scribo could be implemented like that (Scribo annotations are structured, not only a piece of text, even if "serializable" as a text).
Actually this point is supposed to be an iteration in both directions (not only about typed annotations leaving behind the second requirement), and for the annotation target I specified
and one should easily set a field in a structured document which would support annotations.
Ok. Sounds good given your above explanation about annotation definition in a XClass.
Guillaume
* integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
I guess that will depend on its quality by this time. I think it would be a great addition to XE's default feature set.
*Version 1.2* (future)
* finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
I think this can become a key differentiating feature of XWiki since I'm not aware of any wiki that has them implemented yet. MS Word's annotation system is widely used and I think XWiki annotation would resonate positively with XWiki users coming from such text editors.
For the moment I will focus on version 1's tasks while finding a good
architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail),
:-)
Thanks, Anca
Guillaume
Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 10/16/2009 11:12 AM, Guillaume Lerouge wrote:
Hi Anca,
On Fri, Oct 16, 2009 at 10:54 AM, Anca Luca<[email protected]>wrote:
On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
Hi Anca,
On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Anca, Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
I don't have a plan.
Good luck.
The only problem with GWT is that the javascript is not editable right away: it goes through compilation (so the source itself is not the "executable" anymore, as in standard interpreted languages which js is) whereas a jsx, for example, is editable from the wiki. Again, an admin / programmer in a wiki could go in and tweak some js without access to the server fs, or a GWT compiler, or downloading sources, or etc.
However, the main advantage of GWT is its cross-browser-ness, the precious selection API we have and easy development in the more "stable" Java.
Is there a way to have GWT retrieve values for some CSS properties from XObjects?
For instance, is the GWT-based UI could retrieve its CSS color codes from a ColorTheme object it would allow you to code in GWT while still giving the wiki admin some control over the annotations' look.
Is that doable?
Styling was never an issue with GWT code. Editing the source javascript is, and it's not possible to do it. What's doable is to have a mix of GWT and plain javascript, like a core functionality and API in GWT, which is used by a JSX to provide the UI. But this only increases the complexity, and doesn't add the advantages of both frameworks, on the contrary, it only sums their disadvantages. Still, why do you think that GWT is more cross-browser than Prototype? IIRC, there were lots of problems with GWT code, too, and the main problem with both JS and GWT code is not the code itself, but the very general rules in the core skin, which have many side effects hard to overcome. Am I right? So, personally I prefer the Prototype way, but Anca's vote counts more, since she'll have to write the code. By the way, +1 for the general goals, Anca. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 10/16/2009 04:46 PM, Sergiu Dumitriu wrote:
On 10/16/2009 11:12 AM, Guillaume Lerouge wrote:
Hi Anca,
On Fri, Oct 16, 2009 at 10:54 AM, Anca Luca<[email protected]>wrote:
On 10/16/2009 10:44 AM, Guillaume Lerouge wrote:
Hi Anca,
On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca<[email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Anca, Do you plan on using GWT to achieve this? If not, what's the best way to code it in a cross-browser, maintainable way? Using one of the JS library already embedded in XWiki such as Prototype I guess?
I don't have a plan.
Good luck.
The only problem with GWT is that the javascript is not editable right away: it goes through compilation (so the source itself is not the "executable" anymore, as in standard interpreted languages which js is) whereas a jsx, for example, is editable from the wiki. Again, an admin / programmer in a wiki could go in and tweak some js without access to the server fs, or a GWT compiler, or downloading sources, or etc.
However, the main advantage of GWT is its cross-browser-ness, the precious selection API we have and easy development in the more "stable" Java.
Is there a way to have GWT retrieve values for some CSS properties from XObjects?
For instance, is the GWT-based UI could retrieve its CSS color codes from a ColorTheme object it would allow you to code in GWT while still giving the wiki admin some control over the annotations' look.
Is that doable?
the problem is not with looks but with slight adjust of functionality, like, say, extra validation before you click a button, or an extra help message or baloon. If in GWT you need to recompile and redeploy while in jsx you just edit in the browser. Now, this is a frequent use-case only for developers, and edit in browser is a very "nice to have", we need to find out if we're willing to trade.
Styling was never an issue with GWT code. Editing the source javascript is, and it's not possible to do it.
What's doable is to have a mix of GWT and plain javascript, like a core functionality and API in GWT, which is used by a JSX to provide the UI.
I don't think you'd be able to cover all cases where users might want to hack. Since hacking is not supposed to happen (we'd only give one the chance to easily do it if she wants), I think it's very hard to define an API for it.
But this only increases the complexity, and doesn't add the advantages of both frameworks, on the contrary, it only sums their disadvantages.
Still, why do you think that GWT is more cross-browser than Prototype? IIRC, there were lots of problems with GWT code, too, and the main problem with both JS and GWT code is not the code itself, but the very general rules in the core skin, which have many side effects hard to overcome. Am I right?
More or less about the skin rules. GWT might be more cross-browser at least because Marius has been working a lot on making it very cross browser (we have our xwiki-gwt-dom module which encapsulates selection API and the fixes for the DOM api). We can reuse some of this work.
So, personally I prefer the Prototype way, but Anca's vote counts more, since she'll have to write the code.
The whole issue is if it's worth to employ a whole GWT app for such a thing (which might be too light for it). Otherwise GWT has pretty good parts: easier to write code with, automated testing, hosted mode debugging (well, that's achievable with firebug), and all the others that coding in Java brings. Thanks, Anca
By the way, +1 for the general goals, Anca.
On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Sounds good. What do you miss to make it use the "new" architecture fully? Thanks -Vincent
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
*Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail), Anca
Vincent Massol wrote:
On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Sounds good. What do you miss to make it use the "new" architecture fully?
Hi Vincent, I don't think I fully understand what you mean. Can you rephrase, please? Thanks, Anca
Thanks -Vincent
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
*Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail), Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 15, 2009, at 9:08 PM, Anca Luca wrote:
Vincent Massol wrote:
On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Sounds good. What do you miss to make it use the "new" architecture fully?
Hi Vincent, I don't think I fully understand what you mean. Can you rephrase, please?
I meant using components and not plugins. Thanks -Vincent
Thanks, Anca
Thanks -Vincent
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
*Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail), Anca
On 10/16/2009 10:13 AM, Vincent Massol wrote:
On Oct 15, 2009, at 9:08 PM, Anca Luca wrote:
Vincent Massol wrote:
On Oct 14, 2009, at 10:03 PM, Anca Luca wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
Sounds good. What do you miss to make it use the "new" architecture fully?
Hi Vincent, I don't think I fully understand what you mean. Can you rephrase, please?
I meant using components and not plugins.
Of course we're using components, annotation feature is all based on that as we speak. "Plugin" was a general way of referring an XWiki application with a wiki part (a .xar) and one (or several) server side parts (written as components of course). Thanks, Anca
Thanks -Vincent
Thanks, Anca
Thanks -Vincent
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
*Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail), Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca <[email protected]> wrote:
* the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF)
Where is the source for the xwiki-based annotation storage? Is this it? http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentso... some other part of http://hg.nuxeo.org/sandbox/scribo/summary ? Also, I request a simple feature: The addition of an extra, separate, string-property alongside every annotation. This would allow an arbitrary JSON structure (text) to be entered, containing additional information. As my interest is in semantic video and audio annotations, this kind of "back-link" would allow easy addition of structured information alongside an annotation. One of the issues with "annotation" in general is that there can be a variety of information one wants to supply. For example, in a structured document, one may want to annotate a named element, an unnamed-element positionally defined within a larger named structure, as well as an "extent" , in case the annotation doesn't correspond to an exact DOM structure. With streaming media, you will want to annotate with a start and a stop time, but also there may be the need for much additional information to be cross-referenced: for example, if using automatic indexing, structure or dialog detection in a video or audio stream, one will typically have a variety of other information one may need attached to any particular annotation. So in my need for annotation, I may want to include a JSON structure like this alongside every audio annotation: {"title": "Michael Jackson Special", "file": " http://www.aspenpublicradio.com/podcasts/sp/soulpatrol_mjspecialjul09.mp3", "type": "sound", "link": "http://www.aspenpublicradio.org/support.php", "tags": "Music", "image": "/Misc_icon_Media_Clip_1813.jpg", "author": "KAJX, Soul Patrol Podcast", "description": "Clip: segment32 start: 00:15:12.600 end: 00:19:01.400 length: 228.80000000000007s. analyzer=VampQmSegmenter:segment", "date": "2009-07-05T08:00:00Z", "start": 912.6, "duration": 228.80000000000007, "captions.file": "/xwiki/bin/view/Episodes/www_aspenpublicradio_com_podcasts_sp_soulpatrol_mjspecialjul09_mp3?xpage=plain&analyzer=VampQmSegmenter%3Asegment", "trainspodder.analysis": "VampQmSegmenter:segment"} This is from a real-world example: http://nielsmayer.com/trainspodder-prototype-2009-10-16.jpg ... This discussion is timely, as I'm now implementing the functionality behind the "add comment" button in the timeline popup bubble. Thus my interest in finding the source code and it's status for your annotations back-end for use outside your project.... Regarding Scribo, http://trueg.wordpress.com/2009/05/14/scribo-getting-natural-language-into-t... that the main focus is on natural language processing for documents, which is a laudable goal, as I spent some time in college writing in prolog for just this purpose and then spent 8 years in research working alongside NLP people. See before the web existed, we did "web" over email: http://nielsmayer.com/p93-shepherd.pdf and worried about semantic tagging of "intent", and automating conversation structures based on tracking conversational moves.... Today, however, a vast unexplored chunk of content and "intelligence" (and it's dialectic, stupidity) out there is in audio and video form. For that, semantic-audio technologies on which I base my work come in very handy, e.g. http://www.omras2.org/ . Is scribo intending to focus any effort on semantic tagging audio and video content? Given the shared platform, Xwiki, perhaps there's room for collaboration? Also, please note that there is a good deal of potential with the "idiot savant" technology such as that employed by http://www.google.com/voice . Excited to see things from the labs hit the mainstream, I installed my new free google voice "Call Me" button on my website... the performance of the transcription capabilities are less than stellar (it's own "annotation" animated beautifully in synchrony with the recorded message, dynamically underlining each spoken word in the transcript, many of which were completely wrong): *Niels Mayer* () .....11:10 PMHey this is a groovy tester google voice on my homepage. I wanna see how prizes, as I can release my number. What they're gonna do. I have keep number private sector so. Ohh no it's not facts of course it's not gonna do it. Anyways, it's all very excited and an call on the web and see what it actually and they call. -- Niels http://nielsmayer.com
Hi Niels, On 10/16/2009 11:49 PM, Niels Mayer wrote:
On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca <[email protected] <mailto:[email protected]>> wrote:
* the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF)
Where is the source for the xwiki-based annotation storage? Is this it? http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentso... or some other part of http://hg.nuxeo.org/sandbox/scribo/summary ?
The xwiki based storage backend is here in the xwiki sandbox: https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-an... implementing the interfaces in https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-an... . In the scribo sources, they're here (slightly refactored compared to the xwiki sandbox): http://bitbucket.org/lpereira/scribo/src/tip/scribo-xwiki-annotation-parent/... , along with the ScriboIOService implementation.
Also, I request a simple feature: The addition of an extra, separate, string-property alongside every annotation. This would allow an arbitrary JSON structure (text) to be entered, containing additional information.
As my interest is in semantic video and audio annotations, this kind of "back-link" would allow easy addition of structured information alongside an annotation. One of the issues with "annotation" in general is that there can be a variety of information one wants to supply. For example, in a structured document, one may want to annotate a named element, an unnamed-element positionally defined within a larger named structure, as well as an "extent" , in case the annotation doesn't correspond to an exact DOM structure. With streaming media, you will want to annotate with a start and a stop time, but also there may be the need for much additional information to be cross-referenced: for example, if using automatic indexing, structure or dialog detection in a video or audio stream, one will typically have a variety of other information one may need attached to any particular annotation. So in my need for annotation, I may want to include a JSON structure like this alongside every audio annotation:
{"title": "Michael Jackson Special", "file": "http://www.aspenpublicradio.com/podcasts/sp/soulpatrol_mjspecialjul09.mp3", "type": "sound", "link": "http://www.aspenpublicradio.org/support.php", "tags": "Music", "image": "/Misc_icon_Media_Clip_1813.jpg", "author": "KAJX, Soul Patrol Podcast", "description": "Clip: segment32 start: 00:15:12.600 end: 00:19:01.400 length: 228.80000000000007s. analyzer=VampQmSegmenter:segment", "date": "2009-07-05T08:00:00Z", "start": 912.6, "duration": 228.80000000000007, "captions.file": "/xwiki/bin/view/Episodes/www_aspenpublicradio_com_podcasts_sp_soulpatrol_mjspecialjul09_mp3?xpage=plain&analyzer=VampQmSegmenter%3Asegment", "trainspodder.analysis": "VampQmSegmenter:segment"}
This is from a real-world example: http://nielsmayer.com/trainspodder-prototype-2009-10-16.jpg
But this is the requirement number 1 that I mentioned in my original mail: "* be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. " , isn't it? in short, my idea would be that a programmer of the wiki would write (and configure) an xwiki class that would define the type of the annotation that needs to be added, and then the javascript client, UI, communication with server and default xwiki storage) would all automatically handle all the fields in the class, without the need to pass and handle custom JSON. More, right now, the communication between the javascript client and annotations REST service is done in XML, using JAXB for deserialization on the server. So rather than accepting a piece of JSON, more straightforward would be to loosen the schema to accept anything. The sources for the XWiki annotation application are here: https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/ and some user & developer guides are here: http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature . Happy hacking, Anca
... This discussion is timely, as I'm now implementing the functionality behind the "add comment" button in the timeline popup bubble. Thus my interest in finding the source code and it's status for your annotations back-end for use outside your project....
Regarding Scribo, http://trueg.wordpress.com/2009/05/14/scribo-getting-natural-language-into-t... suggests that the main focus is on natural language processing for documents, which is a laudable goal, as I spent some time in college writing in prolog for just this purpose and then spent 8 years in research working alongside NLP people. See before the web existed, we did "web" over email: http://nielsmayer.com/p93-shepherd.pdf and worried about semantic tagging of "intent", and automating conversation structures based on tracking conversational moves....
Today, however, a vast unexplored chunk of content and "intelligence" (and it's dialectic, stupidity) out there is in audio and video form. For that, semantic-audio technologies on which I base my work come in very handy, e.g. http://www.omras2.org/ . Is scribo intending to focus any effort on semantic tagging audio and video content? Given the shared platform, Xwiki, perhaps there's room for collaboration?
Also, please note that there is a good deal of potential with the "idiot savant" technology such as that employed by http://www.google.com/voice . Excited to see things from the labs hit the mainstream, I installed my new free google voice "Call Me" button on my website... the performance of the transcription capabilities are less than stellar (it's own "annotation" animated beautifully in synchrony with the recorded message, dynamically underlining each spoken word in the transcript, many of which were completely wrong):
*Niels Mayer* () ..... 11:10 PM Hey this is a groovy tester google voice on my homepage. I wanna see how prizes, as I can release my number. What they're gonna do. I have keep number private sector so. Ohh no it's not facts of course it's not gonna do it. Anyways, it's all very excited and an call on the web and see what it actually and they call.
-- Niels http://nielsmayer.com
On 10/19/2009 11:20 AM, Anca Luca wrote:
Hi Niels,
On 10/16/2009 11:49 PM, Niels Mayer wrote:
On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca<[email protected] <mailto:[email protected]>> wrote:
* the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF)
Where is the source for the xwiki-based annotation storage? Is this it? http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentso... or some other part of http://hg.nuxeo.org/sandbox/scribo/summary ?
The xwiki based storage backend is here in the xwiki sandbox: https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-an... implementing the interfaces in https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/xwiki-an... .
In the scribo sources, they're here (slightly refactored compared to the xwiki sandbox): http://bitbucket.org/lpereira/scribo/src/tip/scribo-xwiki-annotation-parent/... , along with the ScriboIOService implementation.
Also, I request a simple feature: The addition of an extra, separate, string-property alongside every annotation. This would allow an arbitrary JSON structure (text) to be entered, containing additional information.
As my interest is in semantic video and audio annotations, this kind of "back-link" would allow easy addition of structured information alongside an annotation. One of the issues with "annotation" in general is that there can be a variety of information one wants to supply. For example, in a structured document, one may want to annotate a named element, an unnamed-element positionally defined within a larger named structure, as well as an "extent" , in case the annotation doesn't correspond to an exact DOM structure. With streaming media, you will want to annotate with a start and a stop time, but also there may be the need for much additional information to be cross-referenced: for example, if using automatic indexing, structure or dialog detection in a video or audio stream, one will typically have a variety of other information one may need attached to any particular annotation. So in my need for annotation, I may want to include a JSON structure like this alongside every audio annotation:
{"title": "Michael Jackson Special", "file": "http://www.aspenpublicradio.com/podcasts/sp/soulpatrol_mjspecialjul09.mp3", "type": "sound", "link": "http://www.aspenpublicradio.org/support.php", "tags": "Music", "image": "/Misc_icon_Media_Clip_1813.jpg", "author": "KAJX, Soul Patrol Podcast", "description": "Clip: segment32 start: 00:15:12.600 end: 00:19:01.400 length: 228.80000000000007s. analyzer=VampQmSegmenter:segment", "date": "2009-07-05T08:00:00Z", "start": 912.6, "duration": 228.80000000000007, "captions.file": "/xwiki/bin/view/Episodes/www_aspenpublicradio_com_podcasts_sp_soulpatrol_mjspecialjul09_mp3?xpage=plain&analyzer=VampQmSegmenter%3Asegment", "trainspodder.analysis": "VampQmSegmenter:segment"}
This is from a real-world example: http://nielsmayer.com/trainspodder-prototype-2009-10-16.jpg
But this is the requirement number 1 that I mentioned in my original mail: "* be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. " , isn't it?
in short, my idea would be that a programmer of the wiki would write (and configure) an xwiki class that would define the type of the annotation that needs to be added, and then the javascript client, UI, communication with server and default xwiki storage) would all automatically handle all the fields in the class, without the need to pass and handle custom JSON.
More, right now, the communication between the javascript client and annotations REST service is done in XML, using JAXB for deserialization on the server. So rather than accepting a piece of JSON, more straightforward would be to loosen the schema to accept anything.
The sources for the XWiki annotation application are here: https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-annotation-parent/ and some user& developer guides are here: http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature .
actually the link above contains more implementation details, about usage & setup, it's more here: http://dev.xwiki.org/xwiki/bin/view/Drafts/AnnotationModule . Anca
Happy hacking, Anca
... This discussion is timely, as I'm now implementing the functionality behind the "add comment" button in the timeline popup bubble. Thus my interest in finding the source code and it's status for your annotations back-end for use outside your project....
Regarding Scribo, http://trueg.wordpress.com/2009/05/14/scribo-getting-natural-language-into-t... suggests that the main focus is on natural language processing for documents, which is a laudable goal, as I spent some time in college writing in prolog for just this purpose and then spent 8 years in research working alongside NLP people. See before the web existed, we did "web" over email: http://nielsmayer.com/p93-shepherd.pdf and worried about semantic tagging of "intent", and automating conversation structures based on tracking conversational moves....
Today, however, a vast unexplored chunk of content and "intelligence" (and it's dialectic, stupidity) out there is in audio and video form. For that, semantic-audio technologies on which I base my work come in very handy, e.g. http://www.omras2.org/ . Is scribo intending to focus any effort on semantic tagging audio and video content? Given the shared platform, Xwiki, perhaps there's room for collaboration?
Also, please note that there is a good deal of potential with the "idiot savant" technology such as that employed by http://www.google.com/voice . Excited to see things from the labs hit the mainstream, I installed my new free google voice "Call Me" button on my website... the performance of the transcription capabilities are less than stellar (it's own "annotation" animated beautifully in synchrony with the recorded message, dynamically underlining each spoken word in the transcript, many of which were completely wrong):
*Niels Mayer* () ..... 11:10 PM Hey this is a groovy tester google voice on my homepage. I wanna see how prizes, as I can release my number. What they're gonna do. I have keep number private sector so. Ohh no it's not facts of course it's not gonna do it. Anyways, it's all very excited and an call on the web and see what it actually and they call.
-- Niels http://nielsmayer.com
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 16, 2009, at 10:49 PM, Niels Mayer wrote:
On Wed, Oct 14, 2009 at 1:03 PM, Anca Luca <[email protected]> wrote:
* the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF)
Hi Niels, thank you for your email. I'll try to answer and to clarify things.
Where is the source for the xwiki-based annotation storage? Is this it? http://hg.nuxeo.org/sandbox/scribo/file/a9c5293ae8b3/scribo-xwiki-documentso... some other part of http://hg.nuxeo.org/sandbox/scribo/summary ?
I saw that Anca has already replied to you so I will not repeat what she said. The repository you mentioned is what we called "the scribo framework" that will be used/integrated into XWiki's annotation framework which is currently in a development phase. What you will find in those repos is not really XWiki specific but it is the foundation for building an integration with XWiki (and also with other products that are developed by the partners of the Scribo project). Just to be clearer, Scribo is a research project and currently consists of a "cloud" of heterogeneous and independent technologies developed by several partners, among them several research institutions and industrial partners (including XWiki). You can the links to these technology on this page: http://www.scribo.ws/xwiki/bin/view/Main/Development The project is still in its "initial phases", we are almost at month 10 of 24. We already have some usable stuff but we expect to have something more usable at the beginning of 2010. XWiki's annotation feature will come in a little bit faster :)
Today, however, a vast unexplored chunk of content and "intelligence" (and it's dialectic, stupidity) out there is in audio and video form. For that, semantic-audio technologies on which I base my work come in very handy, e.g. http://www.omras2.org/ . Is scribo intending to focus any effort on semantic tagging audio and video content? Given the shared platform, Xwiki, perhaps there's room for collaboration?
As you already read from Sebastian's blog, Scribo's main focus is about NLP but we also have a workpackage whose focus is about "image dematerialization". In particular it aims at isolating interesting parts of an image (for example the text in a complex picture) or recognizing its structure and assigning "meaning" to the components. Think, for example, to an invoice. It has several areas: the company address, the product list, the recipient of the invoice, etc. In developing Scribo we are trying to reuse open source frameworks and build on them. In particular we are using UIMA as the integration layer. So in principle a technology based on audio/video recognition could be integrated but this is out of the scope of the Scribo project. Concerning XWiki, we have different use cases to implement for the Scribo project and we also have different requirements coming from other sources. The annotation component will try to provide a "common ground" for integrating all those requirements easily (where Scribo will be just one of those integrations) I hope that this answer your mail, feel free to ask other question. Thanks again for your input. Regards, Fabio
Hi all I also added a section about the current implementation along with some schemes about how it works at http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImpleme... . Happy hacking, Anca On 10/14/2009 11:03 PM, Anca Luca wrote:
Hello devs,
The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing).
Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration.
I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles.
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default
*Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation.
What do you think?
For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal.
Thanks (for reading this very long mail), Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Anca Luca -
Fabio Mancinelli -
Guillaume Lerouge -
Niels Mayer -
Sergiu Dumitriu -
Vincent Massol