A dynamically extensible open cross document link service

Editor's Notes

• #5: Extend the link service with Word document
• #7: The same example as before, extension to PDF acrobat Reader
• #8: R1: documents have different models – different anchors, flexible to deal with new document format as well well as emarging document formats … R2: even if R1 is satisfied (in our case) we still need the intervention of developers
• #9: Dashed stuff-----communication
• #10: The extensibity on the linking browser has been realised by having a specific DefaultDocument class that has to be extended by the visual plug-ins for individual document document formats. The DefaultDocument class extends the Jpanel compoenent and offers some necessary methods to visualise any document format and any selector. The user interface instantiate any visual plug-in using the DefaultDocument class. Any local visual plug-in has to implement the abstract methods of the DefaultDocument class which are used by by the browser when visualising a document. Third-party visualisation libraries might be used when implementing a visual plug-in. We have, for example, used the ICEpdf library to implement a local visual plug-in for PDF documents.
• #11: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #12: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #13: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #14: Keep track of available document formats by reading the different plug-ins metadata
• #15: rely mainly on the life cycle layer checks modules metadata download modules via Secure Shell protocol inject modules at run time into OSGi running instance
• #16: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #20: Extend the link service with Word document
• #22: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #24: An interesting idea that can we have adopted to realise the open cross-document service is the proposal of the general cross-media annotation and link architecture by Signer and Norrie, which has been presented in this conference in 2009. The idea of their architecture has never been realised before. It’s basic idea is the separation of linking functionality from the annotated media and using external hyperlinks. The core link and annotation service knows how to deal with the core link and annotation model and is extensible to support new media types. The core linking model is based on the Resource Selector Metamodel which will be explained later. In order to have an extensible architecture Signer and Norrie suggested using data plug-ins for extending the core linking while using visual plug-ins to extend the linking service browser. Normally, when a link or annotation service is extended to support a new media type, also the user interface has to be extended to support the visualization of the new media type. Hence, with the use of visual plug-ins we will avoid a re-implementation and deployment of the entire user interface.
• #25: An interesting idea that can we have adopted to realise the open cross-document service is the proposal of the general cross-media annotation and link architecture by Signer and Norrie, which has been presented in this conference in 2009. The idea of their architecture has never been realised before. It’s basic idea is the separation of linking functionality from the annotated media and using external hyperlinks. The core link and annotation service knows how to deal with the core link and annotation model and is extensible to support new media types. The core linking model is based on the Resource Selector Metamodel which will be explained later. In order to have an extensible architecture Signer and Norrie suggested using data plug-ins for extending the core linking while using visual plug-ins to extend the linking service browser. Normally, when a link or annotation service is extended to support a new media type, also the user interface has to be extended to support the visualization of the new media type. Hence, with the use of visual plug-ins we will avoid a re-implementation and deployment of the entire user interface.
• #27: A central component in the linking architecture is the core link service which is based on the RSL metamodel. The RSL model is based on the concpet of linking arbitrary entities, whereby an entity can either be a resource, a selector or a link. A resource defines a media type such as a text, a video or a complete document. A selector is always attached to a resource and used to address parts of a resource. Finally, a link can be one-to-one, one-to-many, many-to-many bidirectional association between any entities. The core is extensible to support arbitrary document formats by providing a data plug-in consisting of a media-specific implementation of the resource and selector concepts. The data plug-in for a specific document format must provide the definition of its logical structure by extending the RSL resource class and further define how to create selectors within this struccture by extending the RSL selector class.
• #28: The user interface is the linking service browser that visualizes the supported document formats and their hyperlinks. For each document format to be rendered in the browser, a visual plug-in must be implemented. The visual plug-in has two main responsibilities. First it has to render a specific document format and visualise any selectors that have been defined. Second, it should provide functionalities for the basic create, read , update and delete operations for a given document.
• #29: Taking into account that many document formats come along with their own proprietary third-party applications, visual plug-ins also have to be provided for these applications. These external visual plug-ins do not directly support the CRUD operations on the underlying documents, but have to communicate with our link browser in order to exchange information about selectors to be activated or created.
• #30: The extensibity on the linking browser has been realised by having a specific DefaultDocument class that has to be extended by the visual plug-ins for individual document document formats. The DefaultDocument class extends the Jpanel compoenent and offers some necessary methods to visualise any document format and any selector. The user interface instantiate any visual plug-in using the DefaultDocument class. Any local visual plug-in has to implement the abstract methods of the DefaultDocument class which are used by by the browser when visualising a document. Third-party visualisation libraries might be used when implementing a visual plug-in. We have, for example, used the ICEpdf library to implement a local visual plug-in for PDF documents.
• #31: An external visual plug-in has to provide some methods to get and set selections in a document that is visualised in a third-party application. This can be achieved since most document applications provide their own SDKs or APIS. Furthermore, the external visual plug-in also has to provide the GUI actions for the necessary hyperlink CRUD operation which are offered by the browser for the local visual plug-ins. The communication between the linking browser and the external visual plug-in is achieved by a special gateway for the visual plug-in. The gateways is responsible for lunching the third-party application and to communicate information between the browser and visual plug-in. gateways should communicate with their visual plug-ins using a full-duplex communication protocol. However, we have also implemented a REST communication as a fallback in case that the third-party applications SKDs don’t support the full-duplex communication.
• #32: We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
• #33: Each compoenent installed in the OSGI framework has to provide it’s OSGI manifest. In contrast to Java, OSGi modules do not share arbitrary code but they have to explicitly define export packages to be shared and import packages to be used. Hence, due the clear definition of exported functionality, code can’t be misused by other installed modules.
• #34: Here we present a link navigation scenerio. The Registry is a compoent that keep track of all installed visual plug-ins. DocFirmat1 and DocFormat2 are local visual plug-ins while DocFormat3 is an external visual plug-in and this is its gateway. When a user clicks on a hyperlink in a document that is visualised in the browser, the browser communicated with the core RSL to retreive the target document and it’s selectors inclusive the target selector of the selected link. The Registry then is asked for information about the visual plug-in for the target document. If the target document has a local visual plugin, then the command will be forwarded the main class in the visual plug-in , the main class in the class extending the DefaultDocument class, while if it has an external visual plug-in, then gateway will lucnch the application and then forward the request to open the document with its selectors.
• #35: Our cross-document link service currently supports the linking of HTML, PDF, text and XML documents, The browser is able to visualise XML, text and PDF documents via local visual plug-ins while the visualisation of HTML documents in delegated to Google Chrome web browser. This screenshot shows a bi-directioanl link between XML and PDF documents as well as a PDF and HTML documents. For more information about the different document formats data and visual plug-ins please refer to our paper.
• #37: Actually documents do not exist in isolation, but have relationships with other documents. The relationship can be explicit via explicit links or footnotes or can be implicitly established on the similarity of content in different document formats.
• #39: Open Hypermedia systems had a significant impact in enhancing the management of hyperlinks. However, open hypermedia systems had two major shortcomings. First of all, they didn’t investigate the possibilites for creating hyperlinks between snippets of information in different document formats. Second, it is not clear how to extend these systems to support cross-document linking on the model as well as the application layer. Moreover, annotation systems have a significant enhancement for external linking of some document formats. However, they have the same shortcomings as open hypermedia systems. For example, if a new media type has to be supprted in MADCOW which is implemented as a monolithic component, then a new version of the user interface has to be deployed.
• #40: The user interface is the linking service browser that visualizes the supported document formats and their hyperlinks. For each document format to be rendered in the browser, a visual plug-in must be implemented. The visual plug-in has two main responsibilities. First it has to render a specific document format and visualise any selectors that have been defined. Second, it should provide functionalities for the basic create, read , update and delete operations for a given document.
• #41: The user interface is the linking service browser that visualizes the supported document formats and their hyperlinks. For each document format to be rendered in the browser, a visual plug-in must be implemented. The visual plug-in has two main responsibilities. First it has to render a specific document format and visualise any selectors that have been defined. Second, it should provide functionalities for the basic create, read , update and delete operations for a given document.
• #42: Actually documents do not exist in isolation, but have relationships with other documents. The relationship can be explicit via explicit links or footnotes or can be implicitly established on the similarity of content in different document formats.
• #43: A central component in the linking architecture is the core link service which is based on the RSL metamodel. The RSL model is based on the concpet of linking arbitrary entities, whereby an entity can either be a resource, a selector or a link. A resource defines a media type such as a text, a video or a complete document. A selector is always attached to a resource and used to address parts of a resource. Finally, a link can be one-to-one, one-to-many, many-to-many bidirectional association between any entities. The core is extensible to support arbitrary document formats by providing a data plug-in consisting of a media-specific implementation of the resource and selector concepts. The data plug-in for a specific document format must provide the definition of its logical structure by extending the RSL resource class and further define how to create selectors within this struccture by extending the RSL selector class.
• #44: Limitations of the link service extensiblity
• #45: Actually documents do not exist in isolation, but have relationships with other documents. The relationship can be explicit via explicit links or footnotes or can be implicitly established on the similarity of content in different document formats.
• #46: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #47: We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
• #48: We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
• #49: Each compoenent installed in the OSGI framework has to provide it’s OSGI manifest. In contrast to Java, OSGi modules do not share arbitrary code but they have to explicitly define export packages to be shared and import packages to be used. Hence, due the clear definition of exported functionality, code can’t be misused by other installed modules.
• #50: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #51: Taking into account that many document formats come along with their own proprietary third-party applications, visual plug-ins also have to be provided for these applications. These external visual plug-ins do not directly support the CRUD operations on the underlying documents, but have to communicate with our link browser in order to exchange information about selectors to be activated or created.
• #52: We have decided to make use of the open Service Gateway intiative for the development of the link service. The OSGI specifications defines a dynamic modular system for java. Various server applications such as IBM Websphere apply the OSGI framwork and also the eclips IDE uses OSGi to enable the modularaisation of its compoennts as well as to support dynamic extensions via plug-ins. We decided to use it for many reasons, fist of all, it will enhance the modularisation of the linking service. It will also promotes the dynamic extensibility of the linking service. Last but not least, we will avoid the JAR hell in the case of the existence of multiple visual plug-ins for the same document formats.
• #53: To achieve a cross-document linking solution, a number of issues should be taken into account. First of all, many document formats suffer from the fact that they are adding new layers of complexity on top of the existing formats when new features have to be supported. The integration of cross-document linking functionality into existing document formats is atedious and complex task since it requires some knowledge about other document formats. Hence, the solution should not require any chnages to the specficiatoins of existing document formats. Seocnd, it should not make any assumption about types of linked document formats. This one of the main reasons why we think that XLink standartd is not suitable for open cross-document linking since it assumes that the source and target documents have a tree-like document model. Third, it should be extensible to support existing document formats as well as emerging new document formats. Finally, it will be great if the solution can support advance linking features such as bi- and multi-directional links.
• #61: Taking into account that many document formats come along with their own proprietary third-party applications, visual plug-ins also have to be provided for these applications. These external visual plug-ins do not directly support the CRUD operations on the underlying documents, but have to communicate with our link browser in order to exchange information about selectors to be activated or created.