On Fri, Oct 13, 2017 at 1:43 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
You likely didn't get a response because it's not entirely clear from your description what your use case is. In what way do you want to influence the behaviour of the resolvers based on that XSLT state information? Could you give an example of what that information looks like?
Sure. Many of the resolver callbacks are requesting metadata about the document being filtered. By this I mean information about the document which is not found in the XML for the document which is fed to the XSLT engine, such as * which version of the document are we filtering? * what is the official title of the document? * when was the document first published? * from which server/respository/database did we fetch this copy of the document? * what is the repository-specific unique ID for the document we're filtering? There are other examples, but this is a fairly representative list.
PEP 550 would probably solve this, but otherwise, a stackish Python list in thread-local storage doesn't sound all wrong as an approach.
Yes, I agree that it's possible to use that approach, and in fact that's what I'm doing now. It's just that the technique of using the stack to pass stack-specific information seems like the cleanest approach. The ability to attach user-owned data to the parser which was made accessible to the resolver callbacks was one of the few things we liked about the Sablotron package. But as I say, it's not as if we don't have a workable solution. The primary incentive for my original post was to find out if the support was there and I just wasn't looking in the right place for it. I believe I have my answer to that question. :-) -- Bob Kline http://www.rksystems.com mailto:bkline@rksystems.com