Saxon

Legacy ID: #4672712 Legacy Poster: Michael Kay (mhkay)

The method went missing because of a design change in this area that means an application that is using this method probably needs to change anyway. (As the Javadoc makes clear, stable methods in this class are labelled with the "@since" tag, and the copy() method was not one of those methods). The StaticQueryContext class is now used only to initialize context information before compiling a query. Saxon now copies the information to an internal class, QueryModule, which represents one module of a query. The static context information defined in the query prolog of a particular module overwrites the information initialized from the StaticQueryContext object. In the old design, if I remember right, context information initialized by the caller was not effective in library modules, only in the main module. Interface stability between releases has never been a particularly strong point with Saxon, although it has gradually been getting better. I haven't generally gone out of my way to ensure that a new release can be used as a drop-in replacement for a previous release. I'm hoping that matters will improve with the introduction of s9api, which does a much better job of separating the published and public API from the implementation classes and methods that aren't intended to be used by "ordinary" users. However, it's probably still the case that components wanting to achieve close integration with Saxon, like Nux, will end up having dependencies on internals that change from one release to another.

Legacy ID: #4674012 Legacy Poster: Jeremy Volkman (jvolkman)

Thanks for the quick reply, Michael. I resolved my issues with Nux by making it dependent upon StaticContext rather than StaticQueryContext, if that makes sense. Seems to work now. Kudos to you for keeping the API as stable as it has been.