For the tests... There's something to be said for putting 2.0/3.0 tests into the main branch of the test suite and just not invoking then from the default/1.0 target until/unless Xalan reaches a point where it can handle them. We did want these tests to be usable with other processors...
If we just want to extend the existing Xalan architecture to add more recent functionality, it _is_ possible to do that on the main project, simply not declaring compatibility with the higher levels until they're complete and letting the incremental improvements be available for early experimentation (perhaps under control of a switch so the default is still strict 1.0 compatibility.) Keeping a single code stream does have advantages as well as risks. (IBM's 2.0 processor, as I've said, was a new architecture, built around modern compiler design principles -- compile to an abstract instruction set with inlined loops over axes, optimize that including invariant lifting and the like, then generate code from the abstraction.) If we're going to start rewriting, I recommend starting by changing the model access to an abstraction that can be applied over any back-end document model data structure, and make DTM access just one implementation thereof. My solution was to expose the model as something similar to the DOM cursor API -- in fact, the latter was heavily influenced by my work on the former -- rather than as a node tree; that made the axes the primary means if navigation and permitted efficient implementation over DTM, DOM, or indeed over non-XML data structures with some caveats about how to handle the case of non-tree graphs. It's easier to make this cut-over before complicating the data model with the type system, I think. And it positions us better for attempting streaming optimization, I think. (DTM was a solution for the needs of the time. Such heavy compression is no longer required, though there are some things about DTM which are still helpful. Tradeoffs as always.) -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ () Plaintext Ribbon Campaign /\ Stamp out HTML mail! ________________________________ From: Mukul Gandhi <muk...@apache.org> Sent: Wednesday, April 12, 2023 10:52:51 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: XalanJ new git branches Hi Joseph, Thanks for the thoughts, and I agree with you. On Wed, Apr 12, 2023 at 7:45 PM Joseph Kesselman <kesh...@alum.mit.edu> wrote: > > Why would you fork a new development branch from anything but master/main? We shall first, make xalan-java repos's master branch's contents same as that of the branch xalan-j_2_7_1_maint. Then we'll create the branch xalan-j_xslt3.0 from this newly updated master branch. For xalan-test repos, we can directly create branch xalan-j_xslt3.0_tests from the master branch. Please let us know, if there are any gaps, for the above mentioned steps. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
