Reminder for those not familiar with the convention: MUST/MUST NOT: Requirement. Deviation should be avoided if at all possible, should/must be documented while it does exist, and correcting the deviation is a high priority.
SHOULD/SHOULD NOT: Guideline. Often highly recommended, but deviations from this preference are acceptable. They should be documented, justified if they are going to persist, and bringing the project into conformance with the guideline is a medium-high priority. MAY/MIGHT/MIGHT NOT: Suggestion /observation that something be considered. Often a warning to readers that behavior is likely to vary every time or from implementation to implementation. (MAY NOT is avoided since it's ambiguous; colloquially it could be interpreted as either MIGHT NOT, MUST NOT, or SHOULD NOT.) This convention has been in place for decades, dating back at least to the early days of the W3C and I assume going much farther back as a more local practice. If one of these is capitalized or bolded in otherwise unmarked text, you MUST assume these interpretations unless it is clearly stated otherwise. -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. ________________________________ From: Joseph Kesselman <kesh...@alum.mit.edu> Sent: Saturday, December 30, 2023 9:05:25 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: Policy question re src distribution (sorry...) ... the original intent and design of XALAN-TEST is to be a general XSLT standards compliance suite as much as (or more than) tests for the Xalan-J implementation alone. As such, it was a semi-independent project that could be, and was, configured to validate other implementations too. It could be run against Xakan-C with a bit of bridge code, and if I remember correctly even SAXON was testing against it at one point. Yes, some of it is specific to Xalan-J, but most of it -- especially after the adoption of TrAX and JAXP as the javax API -- is not. That doesn't mean we can't bundle it into Xalan and tell folks to fetch Xalan to get a copy of XALAN-TEST; that would be less convenient for its other users but perhaps more convenient for us, especially with the shelving of Xalan-C. On the other hand it means that any unit tests (which we really don't have yet) would want to be kept separate from this compliance suite, and invokes separately, so it isn't clear that folding it into the main is actually the optimal solution. We want to rest against it, it wants to test against us, we own both, but they aren't necessarily one thing; the separation has meaning, though one can argue that the meaning is obsolete. Also, of course, I agree that we SHOULD be looking to reduce the embedded binaries in xalan-test, as I have been doing for Xalan-J. But that doesn't need to happen concurrently with this major change to Xalan-J build; it's a separate task. And should have its own Jira item. I haven't checked whether one already exists; feel free to create it you get to that before I do. But reducing the binaries in its git repository is a separate task from deciding whether to fold it into Xalan-J, and doesn't have to wait for the latter. And I don't think either is at the top of my own priority list right now. I want to get off build for a while. So: Valid points, not blockers to current work, design decisions needed, priority open to discussion, awaiting volunteer to drive them. Should be added to backlog if not already there, probably as two issues rather than one. Or that's how I read it, anyway. There's no shortage of work that should, or SHOULD, be done. -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. ________________________________ From: Vladimir Sitnikov <sitnikov.vladi...@gmail.com> Sent: Saturday, December 30, 2023 2:01:02 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: Policy question re src distribution >In the past, the src tarball/zipfile has included an embedded copy of >xalan-test Please review the release policy https://www.apache.org/legal/release-policy.html#source-packages In particular, they say "A source release SHOULD not contain compiled code". As xalan-test contains many jars with compiled code, you should rather NOT include xalan-test in its current shape into xalan-java source packages. At the same time, they say "Each PMC MUST obey the ASF requirements on approving any release." >Or should xalan-test have its own distros? That would be overhead without much benefit. It would be better to integrate tests into xalan-java code eventually. Vladimir
