Publish-only library

This should provide a solution for people who want to build a website with Daisy, separate from the Daisy Wiki, with high flexibility for customisations, but without having to write all publishing logic from scratch.

The goal is to split of the core document publishing functionality from the Daisy Wiki into a separate project, and let both the Daisy Wiki and potential other clients use that.

Currently there exists an extension component for the repository server, called the Publisher, which allows to retrieve aggregated and preprocessed information from the repository with the goal of supporting the publication process. This Publisher component is what the Daisy Wiki uses.

People who want ultimate control over the publishing process could reuse just the Publisher component, or to have even more control, write their own Publisher-like extension component. Here we are however considering the large base of users who want to reuse the basic Daisy Wiki document publishing model, but outside of the Daisy Wiki.

However, the Daisy Wiki also contains quite some logic for getting a page published:

• the AbstractDocumentApple contains the logic to resolve the requested URL path to a Daisy document (by querying the NavigationManager).
• the DocumentApple will:
• perform a publisher request
• peform document-type specific styling on each 'prepared documents' included in the publisher response (in the case of a document published by the DocumentApple, this will only be one). Each 'prepared documents' can include multiple 'prepared document', one for the requested document and one for each document that it includes (if any). The result of these styling processes are stored in a request attribute.
  The 'document type specific styling' pipeline consists of:
• a transformer that parses cross-references (used in the book-documents)
• a transformer that 'absolutizes' IDs (prefixes ids with 'dsy<docid>' to avoid collisions when multiple documents are combined on one page)
• a transformer that translates the "daisy:" links to the external URL space (both for a's and img's) (and adjusts fragment identifiers to include the 'dsy<docid>' prefix)
• a transformer that parses the column-widths attributes that might be present on tables
• a document-type specific XSL tranform. This should produce an embeddable piece of HTML (thus without html/body tags)
• a i18n transform
• call a pipeline that generates the response, consists of:
• a 'documentlayout.xsl' that creates the basic structure and leaves for the preparedDocuments a special tag <insertStyledDocument styledResultsId="..."/>
• a 'layout.xsl' (wiki specific general layout) (supposes availability of 'PageContext' instance)
• i18n transform (for i18n labels inserted by the previous two xsl's)
• a "IncludePreparedDocumentsTransformer" which will react on the insertStyledDocument tags and insert retrieve the result of the document-type-specific styling from the request attribute where it was stored earlier. This will also nest included documents inside each other.
• an 'ExternalIncludeTransformer' which will process all non-"daisy:" includes that might occur in documents

For retrieving part data (images, attachments), a PartReader is used.

For handling errors, Daisy has its own ErrorGenerator which is able to display the stacktraces of exceptions that happened on the repository server.

The URL space of the Daisy Wiki is very generic and allows to retrieve e.g. the content of each part (thus also for non-images etc.) and that for each version. For publish-only, one probably wants a simpler URL space, and this will have its influence in the places where URLs are constructed.

A more detailed study should be performed to see of each of these items if they have any wiki-specific dependencies, and how they can be generalized.

Many of the components use the "WikiHelper" class to access items provided by the Wiki framework, such as the Repository, the SiteConf of the currently active site, the mountPoint, ...

To avoid double work, there are probably many people who will want to reuse the same document-type specific XSLs in both the wiki as the publish only application. Same holds for skins and site definitions.

As for skins, only a limitted number of things will be required for the publish-only:

• layout.xsl: can be much simpler for publish-only sites, we should consider thus having a separate wikilayout.xsl and publishlayout.xsl.
• the default document-to-html.xsl
• CSS, js & img resources
• others?

Extensions:

• one will probably want to have extensions available for publish-only too.
• can daisy-util.js be compatible/reusable?