We have long been considering whether to add support for XSL tranformations to alpinocorpus. Until now, we decided against, because it was cleaner to let the library user do transformations. However, this poses a problem to a future RemoteCorpusReader: it should implement the CorpusReader interface (and nothing more), but we cannot realistically expect a client to download every XML file matching a query to apply transformations (e.g. in the sentence widget of Dact).
We cannot just implement transformations in the server, because then only RemoteCorpusReader would provide this functionality.
Summary: we need library/server-side XSL transformations.
If this method is called, it will return a normal EntryIterator, with an overloaded version of the ill-fated contents() method. Calling the contents() method would:
Retrieve the XML file.
Apply the given stylesheet.
Return the result of the transformation.
The markerQueries argument can be used to mark nodes using queries (like readMarkQueries). We could have some default behavior, where, if the argument is unspecified, it will use the query specified in the second argument to mark nodes.
This change would make it possible to:
Perform transformations library/server side, making RemoteCorpusReader more speedy.
Potentially solve the problem we have in the statistics window (matching nodes, without the given attribute).
If a comparable read method is provided (readWithStylesheet?), eliminate the libxslt1 dependency in Dact.
We have long been considering whether to add support for XSL tranformations to alpinocorpus. Until now, we decided against, because it was cleaner to let the library user do transformations. However, this poses a problem to a future RemoteCorpusReader: it should implement the CorpusReader interface (and nothing more), but we cannot realistically expect a client to download every XML file matching a query to apply transformations (e.g. in the sentence widget of Dact).
We cannot just implement transformations in the server, because then only RemoteCorpusReader would provide this functionality.
Summary: we need library/server-side XSL transformations.
My proposal is to add a method to CorpusReader:
If this method is called, it will return a normal EntryIterator, with an overloaded version of the ill-fated contents() method. Calling the contents() method would:
The markerQueries argument can be used to mark nodes using queries (like readMarkQueries). We could have some default behavior, where, if the argument is unspecified, it will use the query specified in the second argument to mark nodes.
This change would make it possible to:
Any comments?