Thank you for the notice. > ./drools-compiler/src/main/resources/META-INF/drools-4.0.xsd > ./drools-compiler/src/main/resources/META-INF/drools-5.2.xsd
This is for rules in xml format. The feature is very old and not documented. I think we can deprecate and drop. Filed https://github.com/apache/incubator-kie-drools/issues/6159 > ./drools-compiler/src/main/resources/META-INF/drools-processes-5.0.xsd This is for .rf file (rule flow). It's no longer supported since drools 8. We should clean-up it. Filed https://github.com/apache/incubator-kie-drools/issues/6160 Thanks, Toshiya On Tue, Nov 19, 2024 at 10:16 AM Alex Porcelli <a...@porcelli.me> wrote: > Ohh what the following XSD formats? They might not be directly related > to parser, but it's in the same problem domain I think. > > ./drools-compiler/src/main/resources/META-INF/drools-4.0.xsd > ./drools-compiler/src/main/resources/META-INF/drools-5.2.xsd > ./drools-compiler/src/main/resources/META-INF/drools-processes-5.0.xsd > > On Mon, Nov 18, 2024 at 5:35 AM Alex Porcelli <a...@porcelli.me> wrote: > > > > Thank you for the clarification and the confirmation that the > > DRL6_STRICT enforces the `more correct` form. > > > > I wonder if in the effort to remove ambiguities in the DRL10 parser, > > is the DRL6_STRICT incorporated or the DRL6 mode (not strict) used? > > > > > > On Mon, Nov 18, 2024 at 2:40 AM Toshiya Kobayashi > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > Could you clarify what's exactly the difference between DRL6 Strict > > > > and DRL parsers? Probably the wording STRICT is confusing me, as > > > > usually this term is used to enforce best practices. > > > > > > DRL6_STRICT means "supports strictly typed annotation". > > > > > > DRL6_STRICT parser requires FQCN annotations which need to be resolved > by > > > classloader while DRL6 parser accepts String based annotation names. > Also > > > the annotation position is different (In DRL6_STRICT, annotation is > placed > > > before its target declaration. In DRL6, annotation is placed after its > > > target declaration). There is no difference other than annotation. > > > > > > For example) > > > > > > DRL6_STRICT: > > > > > > import org.example.Xyz; > > > > > > @Xyz rule R1 > > > when > > > then > > > end > > > > > > DRL6: > > > > > > // no need of import for Xyz > > > > > > rule R1 @Xyz > > > when > > > then > > > end > > > > > > Regards, > > > Toshiya > > > > > > On Sun, Nov 17, 2024 at 8:31 PM Alex Porcelli <a...@porcelli.me> > wrote: > > > > > > > Thank you for the clarifications, Thoshiya. > > > > > > > > Could you clarify what's exactly the difference between DRL6 Strict > > > > and DRL parsers? Probably the wording STRICT is confusing me, as > > > > usually this term is used to enforce best practices. > > > > > > > > On Tue, Nov 12, 2024 at 10:28 PM Toshiya Kobayashi > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > Thank you very much for the reply, Alex. > > > > > > > > > > I totally agree with user communication and gradual approach. > > > > > > > > > > Btw, "Strict mode" and "legacy mode" likely don't fit well with the > > > > parser > > > > > architecture. > > > > > > > > > > One parser implementation is tied to one LanguageLevelOption. > > > > > > > > > > In the current codebase, > > > > > > > > > > The new parser -> DRL6 > > > > > The old DRL6 parser -> DRL6 > > > > > The old DRL6_STRICT parser -> DRL6_STRICT > > > > > The old DRL5 parser -> DRL5 > > > > > > > > > > (Sorry, I haven't mentioned the old DRL6_STRICT/DRL5 parsers > before, but > > > > > they exist) > > > > > > > > > > But the proposal is > > > > > > > > > > The new parser -> DRL10 > > > > > The old DRL6 parser -> DRL6 > > > > > The old DRL6_STRICT parser -> DRL6_STRICT > > > > > The old DRL5 parser -> DRL5 > > > > > > > > > > and considering the migration plan. > > > > > > > > > > You seem to assume that the new parser can handle all DRL5, DRL6 > and > > > > DRL10. > > > > > But it can't. > > > > > > > > > > The new parser (DRL10) is itself "strict mode" and the old DRL6 > parser is > > > > > itself "legacy mode". Users can choose any parser as long as they > exist. > > > > > > > > > > So the point is how we will provide warnings. > > > > > > > > > > 1. Introduce the new parser(DRL10), but make it optional (not > enabled by > > > > > default). > > > > > 2. Raise warnings when the syntax to be dropped are used **in the > old > > > > DRL6 > > > > > parser**, saying these syntax are deprecated. > > > > > Raise warnings when DRL5 and DRL6_STRICT are used, saying these > > > > language > > > > > levels are deprecated. > > > > > <six months later> > > > > > 3. Raise warnings when DRL6 is used, saying DRL10 will be the > default in > > > > > the future > > > > > <six months later> > > > > > 4. Make the new parser(DRL10) default > > > > > <xxx months later> > > > > > 5. In the next major release (version 11), drop the old DRL5 and > > > > > DRL6_STRICT parsers > > > > > <xxx months later> > > > > > 6. In the major release after that (version 12), drop the old DRL6 > > > > parser, > > > > > it means the deprecated syntax cannot be used at this point. > > > > > > > > > > How does it sound? > > > > > > > > > > Additional points: > > > > > Until step 3, probably most community users are not aware of the > new > > > > > parser(DRL10) even if documented. We may promote it in the > community and > > > > > collect feedback. > > > > > > > > > > > Additionally, I think eval should be handled differently. It > needs its > > > > > > own thread and likely more discussion, as well as a clear and > careful > > > > > > communication plan for its deprecation. > > > > > > > > > > Agreed. > > > > > > > > > > > Finally, I’d recommend including a migration tool as part of > this plan > > > > > > to help users transition more smoothly. > > > > > > > > > > Agreed. > > > > > > > > > > Regards, > > > > > Toshiya > > > > > > > > > > On Tue, Nov 12, 2024 at 9:41 PM Alex Porcelli <a...@porcelli.me> > wrote: > > > > > > > > > > > Thank you, Toshyia for the proposal! > > > > > > > > > > > > I have a concern about making these changes without the proper > > > > > > communication channels in place. We agreed a while back to focus > on > > > > > > the release first and address communication afterward. > > > > > > > > > > > > Once the communication plan is sorted out, I suggest a more > gradual > > > > > > approach to introduce the new parser: > > > > > > > > > > > > - First, introduce the new parser, but make it optional (not > enabled > > > > > > by default). Start by showing warnings for any syntax that will > be > > > > > > removed, including v5 syntax. > > > > > > - About six months later, add warnings for users not yet using > the new > > > > > > parser, and introduce a "strict mode" (which won’t be enabled by > > > > > > default). > > > > > > - Another six months later, set the new parser as the default. > > > > > > - Enable strict mode by default. > > > > > > - In the next major release (version 11), adopt the new parser > as the > > > > > > default and remove old syntaxes. Add a "legacy mode" to support > older > > > > > > syntaxes, with warnings for their use, and drop v5 syntax. > > > > > > - In the major release after that (version 12), completely > remove all > > > > > > old syntaxes. > > > > > > > > > > > > Additionally, I think eval should be handled differently. It > needs its > > > > > > own thread and likely more discussion, as well as a clear and > careful > > > > > > communication plan for its deprecation. > > > > > > > > > > > > Finally, I’d recommend including a migration tool as part of > this plan > > > > > > to help users transition more smoothly. > > > > > > > > > > > > Alex > > > > > > > > > > > > On Tue, Nov 12, 2024 at 12:26 AM Toshiya Kobayashi > > > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > We have merged a new Antlr4 based DRL parser in the drools main > > > > branch. > > > > > > > It's not enabled by default, so it doesn't affect users now. > > > > > > > > > > > > > > The new parser has been focused on backward compatibility and > > > > existing > > > > > > unit > > > > > > > tests are all green with it. > > > > > > > > > > > > > > However, at this point, we can take an opportunity to "slim > down DRL > > > > > > > syntax" in order to improve the future maintainability of > drools. > > > > > > > > > > > > > > PROPOSAL is > > > > > > > > > > > > > > - Drop or modify some DRL syntax, which cause maintenance cost > and/or > > > > > > > ambiguity and/or are less useful. > > > > > > > - Introduce LanguageLevelOption.DRL10 for the new syntax. > Enabled > > > > when > > > > > > > configured. It is handled by the new parser. > > > > > > > - Announce "deprecate" for the dropped syntax, so that users > can > > > > migrate > > > > > > to > > > > > > > DRL10. > > > > > > > - At some point in the future, make LanguageLevelOption.DRL10 > > > > default. > > > > > > > (Still keep DRL6 and the old parser as a transition period) > > > > > > > - When we consider the new parser is mature, we will remove > DRL6 and > > > > the > > > > > > > old parser > > > > > > > > > > > > > > Further details and candidates syntax to drop are written in > this > > > > docs. > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1Ibmj-koAMbeaungHuFeQtw2zD03YJcNJkJ-kdN8ugks/edit?usp=sharing > > > > > > > > > > > > > > Feel free to add comments on the docs. Discussing this on the > thread > > > > is > > > > > > > also great. > > > > > > > > > > > > > > Thanks! > > > > > > > Toshiya > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
