Saxon

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

I did think quite hard about people in your position, building open source software on top of Saxon, and I knew the decision would cause problems like this. That's one reason I left open the ability to write extension functions for Saxon-HE that use the new "integrated extension function" mechanism: it enables you in effect to supply your own customized variant of evaluate-node() as part of your own application. There's even the possibility that the community will develop a library of such extensions. But I won't be shipping them as part of Saxon-HE. I would suggest you go ahead and ship your current release on 9.1.0.7, and then think about what to do for the future. saxon:memo-function is in a different category: I do see it as a high-value extension that only belongs in the commercial product. You'll have to think about how to work without it, or how to provide your own extension with comparable behaviour.

Legacy ID: #7549663 Legacy Poster: mjk (mjkerpan)

Why DID you decide to even further limit the capabilities of the open source version of Saxon and move them to a proprietary-only version? Aren't you worried about a code fork? Frankly there's getting to be less and less reason to use Saxon, rather than, say xsltproc, as open source Saxon continues to hemorrhage functionality.

Legacy ID: #7549709 Legacy Poster: David Lee (daldei)

I, for one, support the direction Mike is going. While I certainly would love everything for fee, I know what its like to try to make a business and a living as a software developer. Unlike many other 'open source' software which is actually subsidized by large profitable companies, mike is doing this all on his own and I think he deserves to try to make a business model out of it while still offering to the community a free product of exceptional quality and value.

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

>Why DID you decide to even further limit the capabilities of the open source version of Saxon and move them to a proprietary-only version? Because there are too many people making money out of my work and not contributing anything back. >Aren't you worried about a code fork? It's a risk, certainly. But Saxon (even just the open source part) is 270K lines of pretty complex code, and I don't think there are many people capable of developing it further; and if they tried, I'm not sure people would trust the result. One point to note is that the test material for Saxon is several times the size of the source code, and it has not been published. >Frankly there's getting to be less and less reason to use Saxon, rather than, say xsltproc, as open source Saxon continues to hemorrhage functionality. It costs me nothing if I lose a few non-paying users. Certainly, I'm happy to lose ten non-paying users to gain one paying customer. But I don't see it happening: clearly I would not be making this move if it weren't for the fact that Saxon effectively has no competition: no-one else has been able to invest the effort needed to create a high-quality XSLT 2.0 processor and deliver it to the market at zero or low cost.

Legacy ID: #7550422 Legacy Poster: Lea Hayes (numberkruncher)

I respect what you are trying to accomplish with Saxon and I do agree that Saxon is too good to just give away for free. For me the only major losses in the free version are "saxon:evaluate" and "saxon:evaluate-node". I think that these are extremely important for all versions of Saxon. If it is possible to develop a library of integrated extension functions that achieve the same outcome, then I really do not understand why you feel the need to remove these from the free product. I totally appreciate what you say regarding "saxon:memo-function", it should definitely be a feature of the commercial product. To get the best performance you should have to fork out some cash. I had an idea for the commercial variants. Redistributing the Saxon modules is obviously a big no because it is licensed software (and rightly so). What if there were a re-distributable version of Saxon that only supports special compiled stylesheets that have to be compiled with a special utility that is only available when you purchase a commercial license? This would enable software developers to create a product using the professional version, yet still be able to distribute their software in any way they wish. Nobody else could benefit from the re-distributable Saxon modules because it would be constrained to special compiled stylesheets. Otherwise there are new restrictions imposed upon software developers, even if they purchase the commercial options.