2.11 1.5 to 2.0 compatibility

2.11.1 Change to namespaced document IDs

2.11.1.1 Daisy Wiki compatibility

URLs without a namespace still work as before, so installing this new Daisy version will not break all external links (and bookmarks, etc.).

About the navigation: if you have navigation paths in which the node IDs are simply defined by the document ID (which is the default, common way, e.g. /4/6/12) then these will now include the namespace too (e.g. /4-NS/6-NS/12-NS). Since the path ends on the document ID, the navigation manager will still be able to find the document back. If the document would occur on multiple locations in the same navigation tree, you will be redirected to the first occurrence though. If you would use a custom node ID at the end but default document IDs higher up (for example, /4-NS/6-NS/my-custom-node-id), then the link will be broken. However, this is (or at least should be) a rather unusual situation.

2.11.1.2 Queries

The 'id' identifier in the query language now returns the namespaced document ID, thus a string instead of a number.

2.11.1.3 Java API compatibility

Previously, the document ID was represented as a long in the Java API. With the namespaced document IDs this is not possible anymore, therefore it has been changed to a String. Since this is a straightforward change, we have opted to do it in a backwards-incompatible way, instead of making the API more complex.

For compatibility, you can pass in document ID strings without namespace component. The repository server itself will however always use namespaced document IDs in its responses.

Basically, everywhere where you need to supply a document ID in the API, is now should be a string.

Document.getId() returns a string. The VariantKey constructor now takes a String argument.

When building up queries programmatically that include the id identifier, for example "... id = '" + document.getId() + "' and ...", you will now have to embed the id in single quotes since it is now a string.

RepositoryListener interface: the id argument of the repositoryEvent method/callback has been changed from a long to an Object, since document IDs are now strings but the rest of the items remain identified by a long value. The separate variantEvent callback has been removed (the events now also go via the repositoryEvent callback), and the corresponding DocumentVariantEventType has been removed and merged into RepositoryEventType. The latter one now has a convenience method isVariantEvent() to check if the event is about document variants.

2.11.1.4 HTTP API compatibility

In the HTTP API and its XML messages, the document ID is now also replaced by the namespaced document ID. However, in contrast to Java, XML and URLs are just strings, so this API should be fully compatible.