Hi,
we’re using the current GroupDocs Annotation version in production. We store the annotations in the XML format you provided. I was informed that you’re working on a new generation of the Viewer and thus I guess it will concern the Annotation tool as well. Do you plan to change the Annotation format as well? On one hand it would be great as the current format doesn’t really fit our needs, on other hand that will make it incompatible with the current version.
What are your plans in this area?
Thank you,
Mariusz Pala
Hello,
Thank you for your request .
Yes, our product team also works on new generation of the GroupDocs.Annotation library at the moment. Could you please specify your configurations for xml format, which type of storeLogic parameter you use?
If you have any proposition for formats , then please share them with us. We will share your wishes to our product team . And when we will have any news from them, then we will notify you.
----------
Best regards,
Evgen Efimov
http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+
OK, so it looks like the old XML format will no longer be supported. What will happen with the current branch then since we use it in production and we will need support for it in case of bugs?
Do you plan to release a migration tool if we would like to move to the new version?
Concerning annotation format - I’d suggest using some standard format, e.g. XFDF, that would simplify any kind of migration from/to any product. But what drives me crazy in the current format is the fact that the user name is saved as an integer. In our case, or generally speaking in any ECM case, an annotation should have just author as string, creation date as date and then content as the annotation definition in XML format. That’s because in every ECM system an annotation object is saved as a content, in 99% cases as XML (especially XFDF) format. Only author and date attributes are not saved in the content but as additional metadata. Mainly due to the fast that all documents with all annotations are sometimes migrated between repositories. Or the username is changed. In such cases updating the annotations content is not allowed.
Out system integrates with EMC Documentum, Alfresco and Oracle WebCenter, so in case you’d like to discuss it further, don’t hesitate to contact me.
Thank you,
Best Regards,
Mariusz
Hello,
Thank you for your suggestion. I will transfer it to our product team.
Unfortunately no, we will not supports old products after release of the next generation products , unless only it is most critical bug.
Basically, we will support old XML format with new product , but not all variants of types. That's why I asked you about storeLogic parameter. Please specify this parameter, that I will be able to discuss it with our product team.
About migration tool - we plan to create migration documentation for transition from old to new product .
----------
Best regards,
Evgen Efimov
http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+
In our case storeLogic=1, so one annotation per file. Same as in PDF XFDF annotations, same as in all products of your competitors (Brava, OpenAnnotate, ARender etc). That’s the only approach that everybody uses nowadays.
Some of those tools uses Aspose libraries as well and your tool is unfortunately far way behind them.
The main issue we have right now is the way annotations are stored and referenced. Especially that user name as INTEGER.
This is how the other tools reference the annotations:
Annotation:
1. ID - depends on system, LONG or STRING
2. User name - STRING
3. Creation Date - TIME
4. Modify Date - TIME
5. Content as XML which is basically the annotation definition
Then there is an external relation that binds the document and the annotation by ID, relation depends on the backend. That way documents and annotations can be easily migrated and only the references in the relations need to be updated when the ID changes, but it’s handled by default in every system migration utility.
So if the GD Annotation can meet that requirement, we’d be more than happy with upcoming the new version. If it’s just a Viewer change that doesn’t modify the Annotation design you currently have and it required manual update of all the annotations, then unfortunately we need to reconsider using it.
Regards,
Mariusz Pala
Hello,
Thank you for your details.
I have transferred them to our product team. When, I will have any news from the team, then you will be notified.
If you will have more questions please feel free to contact us.
---------
Best regards,
Evgen Efimov
http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+