Implement Metapath regex functions #140
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 WalkthroughWalkthroughThe changes encompass updates across various files in the project, primarily focusing on enhancing the Metapath functionality by implementing the Changes
Assessment against linked issues
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Outside diff range and nitpick comments (15)
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java (2)
10-24: LGTM with suggestions:parseFlagsmethod is well-implemented but could benefit from additional error handling.The
parseFlagsmethod is concise, efficient, and well-documented. The use of Java 8+ stream operations is a good choice for processing the input string. However, consider the following improvements:
- Add input validation to check if the
flagsstring is empty or null (despite the@NonNullannotation, it's a good practice to validate input).- Consider adding a check for duplicate flags to prevent potential issues.
Here's a suggested improvement:
public static int parseFlags(@NonNull String flags) { if (flags == null || flags.isEmpty()) { throw new IllegalArgumentException("Flags string cannot be null or empty"); } return flags.chars() .distinct() // This will remove duplicate flags .map(i -> characterToFlag((char) i)) .reduce(0, (mask, flag) -> mask | flag); }This change adds input validation and removes duplicate flags, which could lead to unexpected behavior if present.
26-49: LGTM with suggestions:characterToFlagmethod is correct but could be optimized.The
characterToFlagmethod correctly maps characters to their correspondingPatternflags and handles invalid inputs. However, consider the following improvements:
- Use an EnumMap or a static final Map for flag mapping, which could improve performance and maintainability.
- Consider using enhanced switch syntax (if using Java 14+) for more concise code.
Here's a suggested improvement using an EnumMap:
private static final Map<Character, Integer> FLAG_MAP = new EnumMap<>(Character.class); static { FLAG_MAP.put('s', Pattern.DOTALL); FLAG_MAP.put('m', Pattern.MULTILINE); FLAG_MAP.put('i', Pattern.CASE_INSENSITIVE); FLAG_MAP.put('x', Pattern.COMMENTS); FLAG_MAP.put('q', Pattern.LITERAL); } private static int characterToFlag(Character ch) { Integer flag = FLAG_MAP.get(ch); if (flag == null) { throw new RegularExpressionMetapathException(RegularExpressionMetapathException.INVALID_FLAG, String.format("Invalid flag '%s'.", ch)); } return flag; }This approach could potentially offer better performance for larger sets of flags and makes it easier to add or modify flags in the future.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java (1)
12-50: LGTM: Error code constants are well-defined and documented.The constants are appropriately named, follow Java conventions, and have detailed Javadoc comments with links to the W3C XPath Functions specification. This aligns well with the PR objectives for implementing regex functions.
Consider adding the actual error code values (e.g., MPRX0001) to the constant names or Javadoc comments for easier reference. For example:
/** * MPRX0001: Raised by regular expression functions... */ public static final int INVALID_FLAG = 1;core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FunctionTestBase.java (1)
100-100: Approved: Consider updating documentation for theexecuteFunctionmethod.The change from
privatetopublicfor theexecuteFunctionmethod is appropriate, as it allows for greater reusability of this utility method in other test classes. This aligns well with the purpose of a base test class.Consider adding or updating the JavaDoc for this method to reflect its new public visibility. This will help other developers understand how and when to use this method in their test cases. For example:
/** * Executes a function with the given context, focus, and arguments. * This method is useful for testing function behavior in various scenarios. * * @param function The function to execute * @param dynamicContext The dynamic context for execution (can be null) * @param focus The focus sequence (can be null for non-focus-dependent functions) * @param arguments The list of argument sequences * @return The result of the function execution * @param <R> The type of items in the result sequence */ public static <R extends IItem> ISequence<R> executeFunction(...)core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatchesTest.java (3)
35-40: LGTM: Class declaration and constants are well-defined.The class name accurately reflects its purpose, and extending
ExpressionTestBaselikely provides common functionality for Metapath expression tests. ThePOEMconstant is well-suited for complex regex testing scenarios.Consider adding a brief comment explaining the purpose of the
POEMconstant and its relevance to the tests. This would enhance code readability and maintainability.
42-76: LGTM: Comprehensive parameterized tests for thematchesfunction.The
provideValuesmethod provides a good range of test cases for thematchesfunction, covering various regex patterns and flags. The parameterized test method correctly utilizes these values and asserts the expected results.Consider adding the following test cases to further improve coverage:
- A test case with an empty string as input.
- A test case with a very long input string to check for any performance issues.
- A test case using more complex regex features like lookaheads or backreferences.
Example:
Arguments.of(bool(true), "matches(\"\", \".*\")"), Arguments.of(bool(true), "matches(string-join((1 to 10000)!string(.)), \"^1.*0$\")"), Arguments.of(bool(true), "matches(\"abc123abc\", \"(?<=\\d)abc\")"),
92-124: LGTM: Well-implemented tests for invalid inputs.The
testInvalidPatternandtestInvalidFlagmethods correctly test for expected exceptions when invalid inputs are provided. They cover important edge cases and follow good practices for exception testing.Consider adding a test case for an empty flag string to ensure it's handled correctly:
@Test void testEmptyFlag() { IBooleanItem result = FunctionTestBase.executeFunction( FnMatches.SIGNATURE_THREE_ARG, newDynamicContext(), ISequence.empty(), List.of(sequence(string("input")), sequence(string("pattern")), sequence(string("")))); assertEquals(bool(true), result); }This would ensure that the function behaves correctly when an empty flag string is provided.
core/src/main/java/gov/nist/secauto/metaschema/core/datatype/markup/IMarkupString.java (1)
116-122: LGTM! Consider adding a minor documentation improvement.The addition of the
toText()method is a valuable enhancement to theIMarkupStringinterface. It provides a clear and consistent way to obtain a plain text representation of the markup content, complementing the existing conversion methods liketoHtml(),toXHtml(), andtoMarkdown().Consider adding a brief note in the method's Javadoc to clarify how the plain text conversion handles any markup elements or special characters. For example:
/** * Converts the markup content to plain text. * + * This method strips all markup elements and returns only the textual content. + * Special characters are handled as follows: [provide brief explanation if needed] * * @return the plain text representation of the markup content */This additional information would help implementers and users understand the exact behavior of the text conversion.
core/src/main/java/gov/nist/secauto/metaschema/core/datatype/markup/AbstractMarkupString.java (1)
211-215: Approve with suggestions: Enhance robustness and documentation oftoText()method.The implementation of
toText()looks good and aligns with the PR objectives. However, consider the following improvements:
- Add a null check for the
documentobject to prevent potential NullPointerExceptions.- Consider adding exception handling for any exceptions that might be thrown by
TextCollectingVisitor.- Add Javadoc for the method to improve documentation.
Here's a suggested implementation with these improvements:
/** * Converts the markup document to plain text. * * @return the plain text representation of the document * @throws IllegalStateException if the document is null */ @Override public String toText() { if (document == null) { throw new IllegalStateException("Document is null"); } try { return new TextCollectingVisitor().collectAndGetText(document); } catch (Exception e) { LOGGER.error("Error collecting text from document", e); return ""; } }This implementation includes a null check, exception handling, and Javadoc. Note that you may want to adjust the exception handling strategy based on your specific requirements.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (1)
Line range hint
184-184: Implementation fortokenize()function is missing.While the
matches()function has been implemented, thetokenize()function mentioned in the PR objectives is still commented out. Consider implementing and registering thetokenize()function to fully meet the PR objectives.To implement the
tokenize()function, you should:
- Create a
FnTokenizeclass with appropriate signatures (similar toFnMatches).- Uncomment line 184 and register the
FnTokenizesignatures.- Add unit tests for the
tokenize()function.Here's a suggested implementation:
- // P1: https://www.w3.org/TR/xpath-functions-31/#func-tokenize + // https://www.w3.org/TR/xpath-functions-31/#func-tokenize + registerFunction(FnTokenize.SIGNATURE_TWO_ARG); + registerFunction(FnTokenize.SIGNATURE_THREE_ARG);databind-metaschema/src/test/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandlerTest.java (2)
43-43: Consider renaming the test method for clarityTo enhance readability and clearly convey the purpose of the test, consider renaming
testValid()to a more descriptive name such astestSarifOutputValidatesAgainstSchema().
107-118: Simplify the assertion logic in theif-elseblockThe
assertTrue(result.isValid());statement in theelseblock is redundant since the conditionresult.isValid()is already known to betrue. You can streamline the code by removing theelseblock and placing the assertion after theifblock.Apply this diff to simplify the code:
if (!result.isValid()) { StringBuilder sb = new StringBuilder(); for (dev.harrel.jsonschema.Error finding : result.getErrors()) { sb.append(String.format("[%s]%s %s for schema '%s'%n", finding.getInstanceLocation(), finding.getKeyword() == null ? "" : " " + finding.getKeyword() + ":", finding.getError(), finding.getSchemaLocation())); } assertTrue(result.isValid(), () -> "Schema validation failed with errors:\n" + sb.toString()); } - else { - assertTrue(result.isValid()); - }core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java (3)
152-161: Expand Exception Handling for Comprehensive CoverageIn the
fnMatchesmethod, exceptions fromPattern.compileandRegexUtil.parseFlagsare caught and rethrown asRegularExpressionMetapathException. Ensure that all possible exceptions, such asNullPointerExceptionor other unchecked exceptions, are appropriately handled or documented. This will enhance the robustness of the method.
24-27: Enhance Javadoc with Detailed Descriptions and ExamplesThe class-level Javadoc provides a reference to the specification but lacks detailed explanations or usage examples. Adding more comprehensive documentation can aid users in understanding how to use the
fn:matchesfunction effectively.
16-20: Organize and Clean Up Import StatementsReview the import statements between lines 16-20 to remove any unused imports, such as
java.util.Listif it's not needed. Organizing imports improves code readability and maintainability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (25)
- .github/workflows/build.yml (6 hunks)
- .github/workflows/release.yml (5 hunks)
- .lycheeignore (1 hunks)
- CONTRIBUTING.md (1 hunks)
- cli-processor/pom.xml (2 hunks)
- core/pom.xml (2 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/datatype/markup/AbstractMarkupString.java (2 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/datatype/markup/IMarkupString.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/model/constraint/ConstraintValidationFinding.java (1 hunks)
- core/src/main/java/module-info.java (1 hunks)
- core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatchesTest.java (1 hunks)
- core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FunctionTestBase.java (1 hunks)
- databind-metaschema/pom.xml (3 hunks)
- databind-metaschema/src/main/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandler.java (3 hunks)
- databind-metaschema/src/test/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandlerTest.java (1 hunks)
- databind/pom.xml (2 hunks)
- metaschema-cli/pom.xml (2 hunks)
- metaschema-maven-plugin/pom.xml (2 hunks)
- metaschema-testing/pom.xml (2 hunks)
- pom.xml (4 hunks)
- schemagen/pom.xml (2 hunks)
🧰 Additional context used
🪛 LanguageTool
CONTRIBUTING.md
[duplication] ~78-~78: Possible typo: you repeated a word
Context: ...eloper information ### Core metaschema functions functions The Metaschema [specification](https:/...(ENGLISH_WORD_REPEAT_RULE)
🔇 Additional comments (61)
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java (3)
1-8: LGTM: Class structure and package declaration are well-defined.The
RegexUtilclass is correctly structured as a final public class within the appropriate package. The necessary imports are present, and the overall setup follows good Java practices for utility classes.
51-53: LGTM: Private constructor prevents instantiation.The private constructor is correctly implemented to prevent instantiation of this utility class. The comment clearly explains its purpose, which is a good practice for maintainability.
1-54: Overall implementation is solid with room for minor improvements.The
RegexUtilclass is well-structured and implements the required functionality for parsing regex flags. It follows Java best practices and conventions. While the implementation is generally correct and efficient, consider the following suggestions:
- Implement the suggested improvements for
parseFlagsandcharacterToFlagmethods.- Add comprehensive unit tests to verify the functionality of both methods, including edge cases and error scenarios.
To ensure proper test coverage, please run the following command to check for the existence of corresponding test files:
If no test files are found, consider adding them to ensure the reliability and correctness of the implementation.
.lycheeignore (1)
18-18: LGTM! Consider verifying the need to ignore Git documentation links.The addition of
https://git-scm.com/documentationto the.lycheeignorefile is consistent with other entries and follows the correct format. This change will prevent Lychee from checking links to Git documentation.While this can reduce false positives and speed up link checking, please ensure that ignoring Git documentation links aligns with your project's needs. If these links are frequently used and integral to your documentation, you might want to keep them checked to ensure they remain valid.
To verify the necessity of this change, you can run the following script:
This script will help you determine if the addition to
.lycheeignoreis necessary based on the actual usage of Git documentation links in your project.✅ Verification successful
Remove the unnecessary Git documentation entry from
.lycheeignore.The entry for
https://git-scm.com/documentationin.lycheeignoreis not needed as it does not appear anywhere in the project. Removing this entry will help maintain a clean and efficient configuration.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for occurrences of Git documentation links in the project # Search for Git documentation links in all files echo "Searching for Git documentation links:" rg --type-add 'text:*.{md,txt,adoc}' --type text 'https://git-scm.com/documentation' # Count the occurrences count=$(rg --type-add 'text:*.{md,txt,adoc}' --type text 'https://git-scm.com/documentation' | wc -l) echo "Total occurrences: $count" # Provide a recommendation based on the count if [ $count -eq 0 ]; then echo "Recommendation: Consider removing the entry from .lycheeignore as no occurrences were found." elif [ $count -lt 5 ]; then echo "Recommendation: The entry in .lycheeignore might be useful, but consider manually verifying these few links." else echo "Recommendation: The entry in .lycheeignore is justified due to frequent usage of Git documentation links." fiLength of output: 540
schemagen/pom.xml (3)
7-7: LGTM: Version update to development snapshotThe parent version has been updated to 1.1.1-SNAPSHOT, which is appropriate for ongoing development. This change allows for new features and bug fixes to be incorporated without immediately creating a release version.
23-23: LGTM: SCM tag updated to HEADThe SCM tag has been changed to HEAD, which is consistent with the move to a snapshot version. This change ensures that the project is tracking the latest commit in the development branch rather than a specific release version.
Line range hint
1-78: Summary: POM file updated for development workThe changes to this POM file are appropriate for starting development work on new features. The version update to a snapshot and the SCM tag change to HEAD are consistent with the PR objectives of implementing new Metapath string functions (fn:matches, fn:replace, and fn:tokenize).
These modifications set the stage for ongoing development and ensure that the project is correctly configured for incorporating new features and bug fixes. The changes are minimal but crucial for maintaining proper version control and development workflow.
cli-processor/pom.xml (3)
6-6: LGTM: Version update to development snapshotThe update of the parent version to 1.1.1-SNAPSHOT is appropriate for ongoing development after the 1.1.0 release. This change aligns with the PR objectives of implementing new Metapath string functions.
23-23: LGTM: SCM tag update to HEADUpdating the SCM tag to HEAD is appropriate for the current development state. This change ensures that the POM reflects the latest commit in the branch, which is consistent with the ongoing implementation of new features.
6-6: Summary: POM updates align with development progressThe changes to the parent version (1.1.1-SNAPSHOT) and SCM tag (HEAD) in this POM file accurately reflect the current state of development. These updates are consistent with the PR objectives of implementing new Metapath string functions and transitioning to ongoing development after the 1.1.0 release.
Also applies to: 23-23
.github/workflows/release.yml (4)
63-63: Consistent use of updated actions/checkout version.This update is consistent with the earlier change to
actions/checkout. Please refer to the previous comment regarding version verification.
Line range hint
20-89: Summary of changes in release.ymlThe changes in this file include:
- Updating
actions/checkoutandactions/setup-javato specific commit hashes.- Adding a CNAME file for custom domain configuration.
These changes improve the workflow's reproducibility and deployment process. Please ensure to verify the action versions as suggested in the previous comments.
75-75: Approve consistent action update and CNAME addition.
- The update to
actions/setup-javais consistent with the earlier change.- The addition of the CNAME file is good for custom domain configuration.
To verify the CNAME configuration, you can run:
#!/bin/bash # Check if the CNAME file is created and contains the correct domain echo "Verifying CNAME file content:" cat target/staging/CNAME # Check if the domain is properly configured in GitHub Pages settings echo "Checking GitHub Pages settings:" gh api repos/:owner/:repo/pages --jq .cnameEnsure that the CNAME file content matches the domain configured in GitHub Pages settings.
Also applies to: 89-89
20-20: Approve the update to actions/checkout, but verify the version.The update to a specific commit hash for the
actions/checkoutaction is good for reproducibility. However, it's worth verifying if this is the latest stable version.To verify the latest version, you can run:
#!/bin/bash # Fetch the latest release version of actions/checkout latest_version=$(gh api repos/actions/checkout/releases/latest --jq .tag_name) echo "Latest stable version of actions/checkout: $latest_version" echo "Current version used in the workflow:" grep -n "actions/checkout@" .github/workflows/release.ymlmetaschema-testing/pom.xml (2)
23-23: LGTM: SCM tag updated to HEADChanging the SCM tag to HEAD is consistent with moving to a snapshot version and ongoing development. This change means the project is now tracking the latest commit in the repository rather than a specific release version.
6-6: LGTM: Parent version updated to development snapshotThe update of the parent version to 1.1.1-SNAPSHOT is appropriate for ongoing development and aligns with the PR objectives of implementing new features.
To ensure consistency across the project, please run the following script:
This script will help identify any pom.xml files that might need to be updated to maintain version consistency.
✅ Verification successful
Verified: Parent version is consistent across all pom.xml files
The parent version
1.1.1-SNAPSHOThas been successfully updated across all relevant pom.xml files, ensuring consistency throughout the project.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify parent version consistency across all pom.xml files # Test: Check for any inconsistencies in parent version rg --type xml -C 5 '<version>1\.1\.1-SNAPSHOT</version>' | rg -v 'metaschema-testing/pom.xml'Length of output: 5727
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java (5)
1-4: LGTM: Package declaration and imports are correct.The package declaration is appropriate for a regex-related exception in the metaschema core, and the import is correct as the class extends AbstractCodedMetapathException.
6-11: LGTM: Class declaration and serialVersionUID are well-defined.The class name is descriptive, follows Java naming conventions, and appropriately extends AbstractCodedMetapathException. The serialVersionUID is correctly defined for serialization compatibility.
52-91: LGTM: Constructors are well-implemented and documented.The three constructors provide flexibility in creating exceptions with different combinations of code, message, and cause. They correctly call the superclass constructors and have clear Javadoc comments following standard conventions.
93-96: LGTM: getCodePrefix method is correctly implemented.The getCodePrefix method is properly overridden and returns "MPRX", which is consistent with the error codes mentioned in the Javadoc comments for the constants.
1-97: Great implementation of RegularExpressionMetapathException!This class provides a solid foundation for handling regex-related exceptions in the Metapath context. It aligns well with the PR objectives and the linked issues (#134 and #135) for implementing regex functions. The error codes and their descriptions are consistent with the W3C XPath Functions specification, which will be helpful for developers working with Metaschema-based software.
A few key points:
- The class structure follows Java best practices.
- Error codes are well-defined and documented.
- Constructors provide flexibility for different exception scenarios.
- The getCodePrefix method ensures consistent error code formatting.
This implementation contributes significantly to the enhancement of the library's functionality for regex operations in Metapath.
core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatchesTest.java (3)
1-34: LGTM: File header and imports are well-organized.The copyright header is present, and the imports are appropriate for the test class. They include necessary JUnit 5 annotations, assertions, and relevant classes from the project.
83-90: LGTM: Well-implementednewDynamicContextmethod.The
newDynamicContextmethod correctly creates a testing context and binds thePOEMconstant to a variable for use in the test cases. The method is well-documented with appropriate JavaDoc comments.
1-125: Overall, excellent test implementation for theFnMatchesfunction.This test class effectively validates the functionality of the
FnMatchesfunction, aligning well with the PR objectives. It provides comprehensive coverage for both positive and negative use cases, including edge cases and invalid inputs. The code is well-structured, follows good testing practices, and uses appropriate JUnit 5 features.The parameterized tests cover a wide range of scenarios, and the individual test methods for invalid cases ensure robust error handling. The
newDynamicContextmethod provides a clean way to set up the testing environment.With the suggested minor improvements, this test class will provide thorough validation for the
matches()function implementation..github/workflows/build.yml (6)
73-73: Approve update to github/codeql-action/analyze action.Updating
github/codeql-action/analyzeto the latest version is important for maintaining the effectiveness of your security scans. It's good to see that this version matches the update for the init action, maintaining consistency.
Line range hint
43-136: Summary of GitHub Actions version updates.All the GitHub Actions version updates in this file are approved. These updates are crucial for maintaining security, leveraging the latest features, and ensuring the reliability of your CI/CD pipeline. The consistency in updating related actions (like the CodeQL actions) is commendable.
To ensure a smooth transition:
- Run the suggested verification scripts for each updated action.
- Test the entire workflow in a non-production environment if possible.
- Monitor the first few runs of this updated workflow closely in production.
These updates align well with the PR objectives of enhancing the project's functionality and maintaining best practices.
62-62: Approve update to github/codeql-action/init action.Updating
github/codeql-action/initto the latest version is crucial for maintaining the effectiveness of your security scans.To ensure compatibility with your project's CodeQL setup, please run the following script:
#!/bin/bash # Description: Verify the compatibility of the new github/codeql-action/init version # Test: Check if the new version is used consistently across the workflow rg --type yaml 'uses:\s*github/codeql-action/init@' .github/workflows/build.yml # Test: Verify if the language specification is still valid rg --type yaml -A 2 'uses:\s*github/codeql-action/init@' .github/workflows/build.yml | rg 'languages:'
136-136: Approve update to peter-evans/create-issue-from-file action.Updating
peter-evans/create-issue-from-fileto the latest version is good practice for maintaining the reliability of your error reporting process.To ensure compatibility with your current issue creation process, please run the following script:
#!/bin/bash # Description: Verify the compatibility of the new peter-evans/create-issue-from-file version # Test: Check if the new version is used consistently across the workflow rg --type yaml 'uses:\s*peter-evans/create-issue-from-file@' .github/workflows # Test: Verify if the issue creation parameters are still valid rg --type yaml -A 5 'uses:\s*peter-evans/create-issue-from-file@' .github/workflows/build.yml
55-55: Approve update to actions/setup-java action.Updating
actions/setup-javato the latest version is a good practice for maintaining security and leveraging the latest features.To ensure compatibility with your project's Java version, please run the following script:
#!/bin/bash # Description: Verify the compatibility of the new actions/setup-java version with the project's Java version # Test: Extract Java version from .java-version file and compare with supported versions java_version=$(cat .java-version) echo "Project Java version: $java_version" # Check if the new action version supports this Java version rg --type yaml "java-version(-file)?:\s*(\${{.*}}|$java_version)" .github/workflows/build.yml
43-43: Approve update to actions/checkout action.The update to a newer version of
actions/checkoutis good practice for maintaining security and benefiting from the latest improvements.To ensure compatibility, please verify that this update doesn't introduce any breaking changes by running the following script:
✅ Verification successful
Further verification needed for actions/checkout update.
Please run the following script to confirm the updated
actions/checkoutversion is correctly applied across all workflow files:
Update to actions/checkout successfully verified.
The
actions/checkoutaction has been updated to versiond632683dd7b4114ad314bca15554477dd762a938across all workflow files, ensuring consistency and leveraging the latest improvements.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the compatibility of the new actions/checkout version # Test: Check if the new version is used in other workflows rg --type yaml 'uses:\s*actions/checkout@' .github/workflowsLength of output: 327
Script:
# #!/bin/bash # Description: Verify the updated actions/checkout version in all workflows rg --type yaml 'uses:\s*actions/checkout@d632683dd7b4114ad314bca15554477dd762a938' .github/workflowsLength of output: 498
databind/pom.xml (3)
7-7: LGTM: Version update for development.The parent version has been updated from 1.1.0 to 1.1.1-SNAPSHOT. This change indicates a transition to a development version, which is appropriate for ongoing work on new features like the Metapath string functions mentioned in the PR objectives.
27-27: LGTM: SCM tag updated for development.The SCM tag has been updated from v1.1.0 to HEAD. This change is consistent with the transition to a development version (1.1.1-SNAPSHOT) and allows the project to track the latest commit in the repository rather than a specific release version. This is appropriate for ongoing development work.
Line range hint
1-214: Summary: POM file updates are appropriate for ongoing development.The changes in this POM file, including the version update to 1.1.1-SNAPSHOT and the SCM tag update to HEAD, are consistent with the ongoing development process. These modifications support the implementation of new features such as the Metapath string functions mentioned in the PR objectives. The changes are appropriate and do not introduce any issues.
metaschema-cli/pom.xml (3)
7-7: LGTM: Version update for ongoing development.The update of the parent version to 1.1.1-SNAPSHOT is appropriate for the ongoing development of new features (fn:matches, fn:replace, and fn:tokenize) as mentioned in the PR objectives.
Line range hint
1-214: Overall assessment: Changes align with PR objectives.The updates to the parent version and SCM tag in this POM file are consistent with the ongoing development of new Metapath string functions (fn:matches, fn:replace, and fn:tokenize) as outlined in the PR objectives. These changes appropriately set up the project for the implementation of these new features.
27-27: LGTM: SCM tag update consistent with ongoing development.The change of the SCM tag to HEAD is appropriate for the current development phase. This ensures that the project references the latest commit in the repository.
To ensure consistency across the project, please run the following script to check if there are any remaining references to the old version tag:
core/src/main/java/gov/nist/secauto/metaschema/core/model/constraint/ConstraintValidationFinding.java (1)
296-296: Improved assertion message for better debugging.The addition of the message "Kind must not be null" to the assertion is a good practice. It enhances the clarity of potential errors during debugging, making it easier to identify the cause of a failure if the
kindvariable is null.databind-metaschema/pom.xml (2)
7-7: LGTM: Version update for development.The parent POM version has been updated to 1.1.1-SNAPSHOT, which is appropriate for ongoing development of new features as described in the PR objectives.
26-26: LGTM: SCM tag updated for development.The SCM tag has been appropriately updated to HEAD, which is consistent with the move to a development version and allows for tracking the latest commit in the development branch.
metaschema-maven-plugin/pom.xml (3)
7-7: Version update to development snapshotThe parent version has been updated to
1.1.1-SNAPSHOT, which indicates a transition to a development snapshot. This change is consistent with the ongoing development of new features mentioned in the PR objectives.
28-28: SCM tag updated to HEADThe SCM tag has been changed to
HEAD, which is appropriate for a development snapshot. This allows for easier tracking of changes during the development process.
Line range hint
1-214: Summary of changes and relation to PR objectivesThe changes in this file are limited to version management updates, specifically the parent version and SCM tag. While these changes support ongoing development, they don't directly implement the new functions (fn:matches, fn:replace, fn:tokenize) mentioned in the PR objectives.
To fully address the PR objectives:
- Ensure that the implementation of the new functions is present in the appropriate Java source files.
- Add or update unit tests for these new functions.
- Update relevant documentation to reflect the new functionality.
To confirm the implementation of the new functions, please run the following script:
This script will help verify the presence of the new function implementations and related test files.
✅ Verification successful
Verification Complete: No Issues Found
The changes in
metaschema-maven-plugin/pom.xmlare limited to version management updates, specifically the parent version and SCM tag. The implementations and tests forfn:matches,fn:replace, andfn:tokenizeare present and properly covered in the codebase. No removed or replaced code is necessary in thepom.xmlfor these updates.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for the implementation of new functions echo "Searching for fn:matches implementation:" rg --type java -i 'fn:matches|matches\s*\(' echo "Searching for fn:replace implementation:" rg --type java -i 'fn:replace|replace\s*\(' echo "Searching for fn:tokenize implementation:" rg --type java -i 'fn:tokenize|tokenize\s*\(' echo "Searching for related test files:" fd -e java -e xml testLength of output: 23758
CONTRIBUTING.md (1)
76-81: Great addition of developer information!The new "Developer information" section provides valuable resources for developers working with Metaschema functions. The links to the specification, conformant library, and registry class are particularly helpful. This addition aligns well with the PR objectives and enhances the documentation for contributors.
🧰 Tools
🪛 LanguageTool
[duplication] ~78-~78: Possible typo: you repeated a word
Context: ...eloper information ### Core metaschema functions functions The Metaschema [specification](https:/...(ENGLISH_WORD_REPEAT_RULE)
core/src/main/java/gov/nist/secauto/metaschema/core/datatype/markup/AbstractMarkupString.java (1)
211-215: Overall assessment: Good addition with minor improvement suggestions.The new
toText()method is a valuable addition to theAbstractMarkupStringclass, aligning well with the PR objectives of enhancing Metapath string functions. It provides a straightforward way to extract plain text from markup documents, which will likely be beneficial for developers working with Metaschema-based software.While the implementation is concise and functional, the suggestions provided in the previous comment (null checking, exception handling, and documentation) would further improve its robustness and usability.
core/pom.xml (2)
7-7: LGTM: Version update for development.The change from version
1.1.0to1.1.1-SNAPSHOTindicates a transition to a development version. This is appropriate for ongoing development and aligns with the PR objectives of implementing new features.
26-26: LGTM: SCM tag update for development.Changing the SCM tag from
v1.1.0toHEADis appropriate for a development version. This allows for easier tracking of changes during the development process and is consistent with the version update to 1.1.1-SNAPSHOT.databind-metaschema/src/main/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandler.java (3)
338-339: LGTM: Adjusting column indices for SARIF compatibilityThe change to increment the column values by 1 when setting
StartColumnandEndColumnis correct. This adjustment ensures that the column numbers in the SARIF output are 1-based, which is the expected format for SARIF reports. Many text editors and IDEs use 0-based indexing internally, so this conversion is necessary for proper integration with tools that consume SARIF data.
494-502: LGTM: Improved handling of identifiers and descriptionsThese changes enhance the robustness and completeness of the SARIF output:
The modified logic for setting the
idensures that aguidis used only when no other identifier is available. This approach maintains existing identifiers when present, improving traceability.Storing the
guidin a variable before use improves code readability and potentially performance by avoiding multiple method calls.The update to the
descriptionhandling now sets both the text and markdown versions, providing more complete information in the SARIF output. This change allows consumers of the SARIF data to choose the most appropriate format for their use case.These improvements align well with the PR objectives of enhancing the library's functionality for Metaschema-based software developers.
Also applies to: 512-514
Line range hint
1-554: Summary: Enhanced SARIF output generationThe changes in this file improve the SARIF output generation in two key areas:
Column indexing: The adjustment ensures compatibility with SARIF's 1-based column indexing, which is crucial for correct integration with tools consuming SARIF data.
Identifier and description handling: The updates provide more robust identifier assignment and more complete description information in the SARIF output.
These enhancements align well with the PR objectives of implementing support for Metapath string functions and improving the library's functionality for Metaschema-based software developers. The changes are well-implemented and should improve the overall quality and usefulness of the SARIF output.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (2)
Line range hint
1-324: Overall implementation looks good, with one missing function.The changes in this file partially address the PR objectives by implementing the
matches()function. The implementation aligns well with the existing structure of theDefaultFunctionLibraryclass and follows the XPath Functions 3.1 specification. However, thetokenize()function mentioned in the PR objectives is still missing.To fully meet the PR objectives:
- Implement and register the
tokenize()function as suggested in the previous comment.- Ensure that unit tests are created for both
matches()andtokenize()functions.- Update relevant documentation to reflect these new function implementations.
105-106: Implementation ofmatches()function looks good.The addition of
FnMatches.SIGNATURE_TWO_ARGandFnMatches.SIGNATURE_THREE_ARGaligns with the PR objective of implementing thematches()function for Metapath use. This implementation follows the XPath Functions 3.1 specification, providing both two-argument and three-argument versions of the function.To ensure completeness, please confirm:
- The actual implementation of
FnMatchesclass exists.- Unit tests have been added to demonstrate both positive and negative use cases for the
matches()function.You can use the following script to verify the implementation and tests:
pom.xml (4)
12-12: Version update looks good.The version has been updated from 1.1.0 to 1.1.1-SNAPSHOT, which is appropriate for ongoing development and aligns with semantic versioning principles.
84-84: Dependency version update is consistent.The javaparser-symbol-solver-core dependency has been updated from version 3.26.1 to 3.26.2. This minor version update is applied consistently throughout the file.
Also applies to: 200-200
90-90: Plugin version updates are appropriate.The following plugin versions have been updated:
- maven-invoker: 3.7.0 to 3.8.0
- pmd: 3.24.0 to 3.25.0
These minor version updates are good practice for maintaining up-to-date build tools.
Also applies to: 92-92
115-115: SCM tag update is consistent with version change.The SCM tag has been updated from v1.1.0 to HEAD, which is appropriate for the development snapshot version 1.1.1-SNAPSHOT.
databind-metaschema/src/test/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandlerTest.java (4)
38-122: Good implementation of the SARIF validation testThe
SarifValidationHandlerTestclass is well-structured and effectively tests the validity of the SARIF output against the schema. The use of mocks and the JSON schema validator is appropriate and contributes to thorough testing.
96-97: Confirm the correctness of the SARIF schema pathVerify that the path to the SARIF schema (
src/test/resources/sarif-schema-2.1.0.json) is correct and that the schema file exists. This ensures that the test will not fail due to a missing or incorrect schema file.Run the following script to check the existence of the schema file:
#!/bin/bash # Description: Verify that the SARIF schema file exists at the specified path. # Test: Check for the existence of sarif-schema-2.1.0.json. # Expect: The file should exist in the specified directory. test -f src/test/resources/sarif-schema-2.1.0.json && echo "Schema file exists." || echo "Schema file is missing."
86-91: Validate addition of findings to the handlerEnsure that the
ConstraintValidationFindingbuilder is correctly configured and that all required fields are set. This is crucial for accurate reporting in the SARIF output.Run the following script to confirm that the builder patterns are used correctly:
✅ Verification successful
Verified: ConstraintValidationFinding builder is correctly configured
The usage of
ConstraintValidationFinding.builderinSarifValidationHandlerTest.javahas been confirmed to properly chain methods ending with.build(). All required fields are set for accurate SARIF reporting.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for correct usage of ConstraintValidationFinding.builder in the codebase. # Test: Search for ConstraintValidationFinding builder usage. # Expect: Proper chaining of methods ending with .build() rg --type java 'ConstraintValidationFinding\.builder' -A 5Length of output: 109
Script:
#!/bin/bash # Description: Verify correct usage of ConstraintValidationFinding.builder in the Java codebase. # Using ast-grep to find ConstraintValidationFinding.builder patterns that end with .build() ast-grep --lang java --pattern ' ConstraintValidationFinding.builder($_, $_) .kind($_) .build() 'Length of output: 577
45-83: Ensure comprehensive mock expectationsWhile the current mock expectations cover the necessary methods, consider verifying that all interactions with the mock objects are accounted for. This can help prevent unexpected behaviors if the underlying implementation changes.
Run the following script to check for any unfulfilled expectations:
✅ Verification successful
All mock interactions are comprehensively defined
The test
SarifValidationHandlerTest.javahas comprehensive mock expectations. No methods are called on mock objects without corresponding expectations.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all mock interactions are defined in the test. # Test: Search for methods used on mocks without corresponding expectations. # Expect: All methods used on mocks should have expectations set in the test. rg --type java '\.(\w+)\(' --only-matching --no-filename | sort | uniq -cLength of output: 45448
Script:
#!/bin/bash # Extract methods called on mock objects in SarifValidationHandlerTest.java TEST_FILE="databind-metaschema/src/test/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandlerTest.java" # Extract all method calls on mock objects rg 'mock\(\w+\)\.(\w+)\(' "$TEST_FILE" --only-matching --no-filename | sed -E 's/mock\(\w+\)\.(\w+)\(.*/\1/' | sort | uniq > methods_called_on_mocks.txt # Extract all methods with expectations set using 'allowing' rg 'allowing\(\w+\)\.(\w+)\(' "$TEST_FILE" --only-matching --no-filename | sed -E 's/allowing\(\w+\)\.(\w+)\(.*/\1/' | sort | uniq > methods_with_expectations.txt # Find methods called on mocks without corresponding expectations comm -23 <(sort methods_called_on_mocks.txt) <(sort methods_with_expectations.txt) > methods_without_expectations.txt echo "Methods called on mocks without expectations:" cat methods_without_expectations.txtLength of output: 887
Script:
#!/bin/bash # Extract methods called on mock objects in SarifValidationHandlerTest.java TEST_FILE="databind-metaschema/src/test/java/gov/nist/secauto/metaschema/modules/sarif/SarifValidationHandlerTest.java" # Extract all method calls on mock objects rg 'mock\(\w+\)\.(\w+)\(' "$TEST_FILE" --only-matching --no-filename | sed -E 's/mock\(\w+\)\.(\w+)\(.*/\1/' | sort | uniq > methods_called_on_mocks.txt # Extract all methods with expectations set using 'allowing' rg 'allowing\(\w+\)\.(\w+)\(' "$TEST_FILE" --only-matching --no-filename | sed -E 's/allowing\(\w+\)\.(\w+)\(.*/\1/' | sort | uniq > methods_with_expectations.txt # Find methods called on mocks without corresponding expectations using grep echo "Methods called on mocks without expectations:" > methods_without_expectations.txt while read -r method; do if ! grep -Fxq "$method" methods_with_expectations.txt; then echo "$method" >> methods_without_expectations.txt fi done < methods_called_on_mocks.txt cat methods_without_expectations.txtLength of output: 724
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java (2)
163-165: Good Practice with Private Constructor in Utility ClassThe private constructor at lines 163-165 effectively prevents instantiation of the
FnMatchesutility class. This is a good practice for classes that only contain static methods.
113-115:⚠️ Potential issueVerify Handling of Null Input in
executeMethodWhen the
inputparameter isnull, theexecutemethod returns an empty sequence. According to the XPath Functions specification forfn:matches, if the$inputargument is the empty sequence, it should be treated as an empty string (""). Verify whether returning an empty sequence is the intended behavior or if it should process an empty string instead.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (8)
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/IStringItem.java (1)
67-69: LGTM! Consider adding method documentation.The addition of the
normalizeSpace()method is a good enhancement to theIStringIteminterface. The@NonNullannotation ensures null-safety, which is a good practice.Consider adding Javadoc for this new method to explain its purpose and behavior. For example:
/** * Normalizes the whitespace in the string. * * @return a new IStringItem with normalized whitespace */ @NonNull IStringItem normalizeSpace();This documentation will help developers understand the method's purpose and usage.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/AbstractStringItem.java (2)
18-21: LGTM: Well-defined regex patterns for whitespace normalization.The static Pattern objects are correctly implemented for efficient whitespace normalization. The naming is clear and follows best practices.
Consider combining TRIM_START and TRIM_END into a single TRIM_BOTH pattern for potential performance improvement:
- private static final Pattern TRIM_END = Pattern.compile(WHITESPACE_SEGMENT + "++$"); - private static final Pattern TRIM_START = Pattern.compile("^" + WHITESPACE_SEGMENT + "++"); + private static final Pattern TRIM_BOTH = Pattern.compile("^" + WHITESPACE_SEGMENT + "++|" + WHITESPACE_SEGMENT + "++$");This could simplify the
normalizeSpace()method and potentially improve performance by reducing the number of regex operations.
64-72: LGTM: normalizeSpace() method implemented correctly.The
normalizeSpace()method effectively normalizes whitespace in the string value, handling trimming at the start, end, and middle of the string. It correctly returns a newIStringItem, preserving immutability.If you implement the TRIM_BOTH pattern suggestion from the previous comment, you could optimize this method:
@Override public IStringItem normalizeSpace() { String value = asString(); - value = TRIM_START.matcher(value).replaceFirst(""); + value = TRIM_BOTH.matcher(value).replaceAll(""); value = TRIM_MIDDLE.matcher(value).replaceAll(" "); - value = TRIM_END.matcher(value).replaceFirst(""); return IStringItem.valueOf(value); }This change would reduce the number of regex operations from three to two, potentially improving performance.
core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java (2)
29-52: LGTM: Well-structured class and comprehensive test data provider.The class structure and test data provider are well-organized. The test cases cover various scenarios for the
tokenizefunction, including whitespace handling, comma-separated values, and case-insensitive matching.Consider adding a comment above the
provideValues()method to briefly explain the purpose of each test case. This would enhance readability and make it easier for other developers to understand and maintain the tests.
62-111: LGTM: Comprehensive exception testing.The exception test methods effectively cover important edge cases for the
tokenizefunction, including zero-length string matches, invalid regex patterns, and invalid flags. The use ofassertThrowsand verification of specific error codes is correct.For consistency, consider extracting the common exception-throwing logic into a private helper method. This would reduce code duplication and make the tests more maintainable. For example:
private void assertTokenizeThrows(FnTokenize.Signature signature, List<ISequence<?>> args, String expectedErrorCode) { RegularExpressionMetapathException throwable = assertThrows(RegularExpressionMetapathException.class, () -> { try { FunctionTestBase.executeFunction(signature, newDynamicContext(), ISequence.empty(), args); } catch (MetapathException ex) { throw ex.getCause(); } }); assertEquals(expectedErrorCode, throwable.getCode()); }Then, you can simplify the exception test methods to use this helper method.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (2)
104-106: LGTM! Consider adding brief documentation.The addition of
FnMatchesfunction registrations aligns well with the PR objective to implement thematches()function. Both two-argument and three-argument versions are correctly implemented, following the XPath specification.Consider adding a brief comment explaining the difference between the two-argument and three-argument versions of the
matchesfunction. This would enhance code readability and help developers choose the appropriate version.
165-168: LGTM! Consider adding brief documentation.The addition of
FnTokenizefunction registrations aligns perfectly with the PR objective to implement thetokenize()function. All three versions (one-argument, two-argument, and three-argument) are correctly implemented, following the XPath specification.Consider adding a brief comment explaining the differences between the one-argument, two-argument, and three-argument versions of the
tokenizefunction. This would improve code readability and assist developers in selecting the appropriate version for their use case.core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java (1)
207-207: UseArrayListinstead ofLinkedListfor better performance.Since we are adding elements sequentially to the end of the list, using an
ArrayListprovides better performance than aLinkedListdue to lower memory overhead and faster access times.Apply this diff to change to
ArrayList:-import java.util.LinkedList; +import java.util.ArrayList; ... List<String> result = new LinkedList<>(); +List<String> result = new ArrayList<>();
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
- core/metaschema (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (2 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/AbstractStringItem.java (2 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/IStringItem.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/UuidItemImpl.java (1 hunks)
- core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- core/metaschema
🚧 Files skipped from review as they are similar to previous changes (3)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java
🔇 Additional comments (12)
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/UuidItemImpl.java (3)
57-61: LGTM: Correct implementation ofnormalizeSpace()for UUIDThe implementation of
normalizeSpace()is correct for a UUID:
- UUIDs have a fixed format without whitespace, so no normalization is needed.
- Returning
thispreserves the immutability of the UUID.- The
@Overrideannotation is correctly used.- The method signature is consistent with the
IStringIteminterface.This implementation ensures that any calls to
normalizeSpace()on a UUID will not modify its value, which is the expected behavior.
57-61: Overall impact: Positive addition toUuidItemImplThe addition of the
normalizeSpace()method:
- Completes the
IStringIteminterface implementation for UUIDs.- Maintains UUID immutability and integrity.
- Ensures consistent behavior in
IStringItemcontexts.- Introduces no breaking changes or side effects.
This change enhances the class's compatibility with the broader system while preserving its core functionality.
57-61: Indirect contribution to PR objectivesWhile this change doesn't directly implement the
fn:matchesorfn:tokenizefunctions mentioned in the PR objectives, it does contribute to the overall consistency of string-related operations in the system. ThenormalizeSpace()method ensures that UUIDs can be used seamlessly in contexts where string normalization might be applied, which could be relevant when implementing the mentioned functions elsewhere in the codebase.core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/IStringItem.java (1)
Line range hint
1-69: Verify implementation of other mentioned functionsThe PR objectives mention implementing
fn:matchesandfn:tokenizefunctions. WhilenormalizeSpace()has been added, I don't see the implementation of these other functions in this file.Could you please confirm if
fn:matchesandfn:tokenizeare implemented in other files? If so, it would be helpful to review those implementations as well. If they haven't been implemented yet, consider updating the PR description to reflect the current state of the implementation.✅ Verification successful
Implementation of
fn:matchesandfn:tokenizeConfirmedThe functions
fn:matchesandfn:tokenizeare implemented in the following files:
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.javacore/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.javaNo further action is required in
IStringItem.javaregarding these functions.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for fn:matches and fn:tokenize implementations echo "Searching for fn:matches implementation:" rg --type java "fn:matches" -g "!test*" echo "\nSearching for fn:tokenize implementation:" rg --type java "fn:tokenize" -g "!test*"Length of output: 1887
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/AbstractStringItem.java (2)
11-11: LGTM: Import statement added correctly.The import for
java.util.regex.Patternis necessary for the new regex functionality and is placed appropriately with other import statements.
Line range hint
1-73: Overall implementation looks good, but unit tests are needed.The changes successfully implement the
normalizeSpace()function, enhancing the Metapath string functions as intended in the PR objectives. The implementation is correct and efficient, with some minor optimization suggestions provided.To ensure the correctness and robustness of the new
normalizeSpace()function, please add comprehensive unit tests. These tests should cover:
- Trimming leading whitespace
- Trimming trailing whitespace
- Normalizing multiple spaces between words
- Handling strings with only whitespace
- Handling strings with no whitespace
- Handling empty strings
- Handling strings with various whitespace characters (spaces, tabs, newlines)
You can use the following script to check for existing tests:
If the script doesn't find any relevant tests, please add them to ensure the new functionality is properly validated.
core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java (4)
1-7: LGTM: Appropriate file header and package declaration.The SPDX license header and package declaration are correct and follow best practices.
8-28: LGTM: Appropriate import statements.All import statements are necessary and correctly used in the test class. There are no unused imports.
54-60: LGTM: Well-implemented parameterized test.The
testmethod effectively uses JUnit 5's parameterized test feature to validate thetokenizefunction with various inputs. The assertion compares the expected sequence with the result of evaluating the Metapath expression.
1-112: Overall: Excellent test implementation for theFnTokenizefunction.This test class thoroughly covers the functionality of the
tokenize()function, addressing the objectives mentioned in issue #135. The implementation includes:
- A comprehensive set of parameterized tests covering various use cases.
- Specific tests for exception scenarios, ensuring robust error handling.
The test class structure is clear, and the use of JUnit 5 features is appropriate. This implementation will help ensure the reliability and correctness of the
tokenize()function in the Metapath processor.To ensure that this test class covers all the requirements mentioned in issue #135, please run the following script:
This script will help verify that the test class meets the requirements specified in issue #135, including the presence of both positive and negative test cases, as well as ensuring that the CI-CD build process runs without errors related to this test.
✅ Verification successful
To ensure that the CI-CD build process for
FnTokenizeTestruns without errors, please execute the following updated script:
Verification Successful:
FnTokenizeTestcovers all required aspects.The
FnTokenizeTestclass includes:
- Comprehensive positive and negative test cases.
- Robust exception handling tests.
- Successful CI-CD build without related errors.
This confirms that the test implementation meets the objectives outlined in issue #135 and ensures the reliability of the
tokenize()function in the Metapath processor.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the FnTokenizeTest class covers all required aspects mentioned in issue #135 # Test: Check for the presence of both positive and negative test cases echo "Checking for positive and negative test cases:" rg -n "Arguments\.of\(" core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java echo "Checking for exception test cases:" rg -n "void test.*Exception" core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java # Test: Verify that the CI-CD build process runs without errors related to this test echo "Checking CI-CD build logs for errors related to FnTokenizeTest:" gh run list --limit 1 --json conclusion,jobs --jq '.[] | .jobs[] | select(.name == "build") | .conclusion'Length of output: 1060
Script:
#!/bin/bash # Description: Verify that the FnTokenizeTest class CI-CD build passes without errors echo "Checking CI-CD build logs for errors related to FnTokenizeTest:" gh run list --limit 1 --json conclusion --jq '.[].conclusion'Length of output: 208
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (1)
Line range hint
1-300: Overall, excellent implementation ofmatches()andtokenize()functions.The changes in this file accurately address the PR objectives by implementing the
matches()andtokenize()functions as per the XPath specification. The code is well-structured, consistent with the existing codebase, and focused on the required functionality.To ensure that these new functions are properly integrated and don't conflict with existing code, please run the following verification script:
This script will help ensure that the new functions are properly implemented and don't conflict with existing code.
✅ Verification successful
Verification Successful:
matches()andtokenize()Functions Properly IntegratedThe
DefaultFunctionLibrary.javafile correctly integrates thematches()andtokenize()functions without introducing any conflicts. All new functions are properly registered, and their usage in other parts of the codebase does not indicate any potential issues.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of new functions and check for potential conflicts # Test 1: Check if FnMatches and FnTokenize classes exist echo "Checking for FnMatches and FnTokenize classes:" rg -t java "class (FnMatches|FnTokenize)" # Test 2: Verify that no other parts of the codebase are using these function names incorrectly echo "Checking for potential conflicts with new function names:" rg -t java "\b(matches|tokenize)\b" --glob '!**/DefaultFunctionLibrary.java' # Test 3: Look for any TODO comments related to these functions echo "Checking for related TODO comments:" rg -t java "TODO.*\b(matches|tokenize)\b"Length of output: 18344
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java (1)
195-231: Handle edge cases where the pattern matches at the start or end of the input.In the
fnTokenizemethod, when the pattern matches at the start or end of the input string, the current implementation may incorrectly add empty strings to the result list. Ensure that the behavior aligns with the XPath specifications, which state that zero-length tokens at the start or end should be omitted unless the pattern can match zero-length strings.Run the following script to test the edge cases and verify the correctness:
Note: Replace
path/to/your/classeswith the actual classpath and ensure thatFnTokenizeTestis a test class that invokesfnTokenizewith the given arguments.
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java
Outdated
Show resolved
Hide resolved
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 15
🧹 Outside diff range and nitpick comments (11)
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/UuidItemImpl.java (1)
57-61: LGTM! Consider adding a brief comment explaining the no-op behavior.The
normalizeSpace()method is correctly implemented as a no-op operation, which is appropriate for a UUID. Returningthisis the right approach as UUIDs don't require space normalization.Consider adding a brief comment explaining why this is a no-op operation for better code readability:
@Override public IStringItem normalizeSpace() { - // noop + // No-op: UUIDs don't contain spaces, so normalization is unnecessary return this; }core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/IStringItem.java (1)
67-69: Approve the addition ofnormalizeSpace()method and suggest documentation.The new
normalizeSpace()method is a good addition to theIStringIteminterface. It follows the existing coding style and conventions, and the@NonNullannotation helps prevent null pointer exceptions.Consider adding Javadoc comments to describe the method's behavior, specifically:
- What exactly does "normalize space" mean in this context?
- Does it trim leading/trailing whitespace, collapse multiple spaces, or both?
- Is the original string modified, or is a new
IStringIteminstance returned?Here's a suggested Javadoc comment:
/** * Normalizes the whitespace in the string representation of this item. * * @return A new IStringItem with normalized whitespace. The original item remains unchanged. */ @NonNull IStringItem normalizeSpace();core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/AbstractStringItem.java (2)
64-72: LGTM: Well-implementednormalizeSpace()method with a minor optimization suggestion.The
normalizeSpace()method is correctly implemented, applying the regex patterns in the right order to normalize whitespace. It maintains immutability by returning a newIStringIteminstance.Consider chaining the regex operations for a slight performance improvement:
- String value = asString(); - value = TRIM_START.matcher(value).replaceFirst(""); - value = TRIM_MIDDLE.matcher(value).replaceAll(" "); - value = TRIM_END.matcher(value).replaceFirst(""); + String value = TRIM_END.matcher( + TRIM_MIDDLE.matcher( + TRIM_START.matcher(asString()).replaceFirst("") + ).replaceAll(" ") + ).replaceFirst("");This change reduces the number of intermediate
Stringobjects created.
64-72: Add JavaDoc for thenormalizeSpace()method.While the implementation is correct, it would be beneficial to add JavaDoc comments for the
normalizeSpace()method. This documentation should explain the method's purpose, behavior, and return value.Consider adding the following JavaDoc:
/** * Normalizes the whitespace in the string value. * This method trims leading and trailing whitespace and replaces sequences * of whitespace characters with a single space. * * @return a new IStringItem with normalized whitespace */ @Override public IStringItem normalizeSpace() { // ... (existing implementation) }core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (1)
104-106: LGTM! Consider adding a brief comment for clarity.The addition of
FnMatches.SIGNATURE_TWO_ARGandFnMatches.SIGNATURE_THREE_ARGsuccessfully implements thematches()function as per the PR objectives. This implementation aligns with the XPath specification by providing both two-argument and three-argument versions.Consider adding a brief comment explaining the difference between the two-argument and three-argument versions of the
matchesfunction for better documentation. For example:// Two-arg signature: matches(input, pattern) registerFunction(FnMatches.SIGNATURE_TWO_ARG); // Three-arg signature: matches(input, pattern, flags) registerFunction(FnMatches.SIGNATURE_THREE_ARG);core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java (4)
26-27: Simplify flag mapping with method references.You can simplify the lambda expression by using a method reference for
characterToFlag.Apply this diff to simplify the code:
return flags.codePoints() - .map(i -> characterToFlag((char) i)) + .map(RegexUtil::characterToFlag) .reduce(0, (mask, flag) -> mask | flag);
30-53: Consider supporting additional regex flags.Currently, only a subset of the possible regex flags are supported. If applicable, consider adding support for flags like
ufor Unicode-aware case folding.
49-51: Provide more informative exception messages.The exception message could include additional context, such as listing the valid flags, to aid in debugging.
Apply this diff to enhance the exception message:
default: throw new RegularExpressionMetapathException(RegularExpressionMetapathException.INVALID_FLAG, - String.format("Invalid flag '%s'.", ch)); + String.format("Invalid flag '%s'. Valid flags are: s, m, i, x, q.", ch));
55-57: Add a comment for the private constructor.While it's clear that the private constructor disables instantiation, adding a comment can improve code readability.
Apply this diff to add a comment:
private RegexUtil() { + // Prevent instantiation // disable construction }core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java (1)
32-32: Clarify the suppression commentThe comment
// NOPMD - false positiveis used to suppress a PMD warning. Consider specifying which PMD rule is being suppressed to provide clearer context for future maintainers.Apply this diff to specify the suppressed rule:
- private static Stream<Arguments> provideValues() { // NOPMD - false positive + @SuppressWarnings("PMD.MethodReturnsInternalArray") // Suppressing specific PMD warning + private static Stream<Arguments> provideValues() {core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java (1)
195-237: Document exceptions thrown by thefnTokenizemethodThe
fnTokenizemethod can throwRegularExpressionMetapathExceptiondue to invalid patterns, flags, or if the pattern matches a zero-length string. Documenting these exceptions in the Javadoc improves code readability and helps users understand potential error cases.Update the method Javadoc to include
@throwstags:/** * Implements <a href= * "https://www.w3.org/TR/xpath-functions-31/#func-tokenize">fn:tokenize</a>. * * @param input * the string to match against * @param pattern * the regular expression to use for matching * @param flags * matching options + * @throws RegularExpressionMetapathException + * if the pattern syntax is invalid, the flags are invalid, or the pattern matches a zero-length string * @return the list of tokens */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (13)
- core/metaschema (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (2 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/AbstractStringItem.java (2 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/IStringItem.java (1 hunks)
- core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/UuidItemImpl.java (1 hunks)
- core/src/main/java/module-info.java (1 hunks)
- core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatchesTest.java (1 hunks)
- core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java (1 hunks)
- core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FunctionTestBase.java (1 hunks)
🔇 Additional comments (14)
core/metaschema (1)
1-1: Submodule update approved. Verify alignment with PR objectives.The submodule commit has been updated, which is a standard practice for keeping dependencies up-to-date. This change looks good from a version control perspective.
To ensure this update aligns with the PR objectives, please run the following verification:
This script will help verify that the submodule update includes the implementations of
fn:matchesandfn:tokenizeas mentioned in the PR objectives. Please review the output to ensure it aligns with the expected changes.core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/UuidItemImpl.java (1)
57-61: Overall, the changes enhance the class's compliance with theIStringIteminterface.The addition of the
normalizeSpace()method complements the existing functionality without introducing any breaking changes. It maintains the integrity of the UUID representation while adhering to the expected interface contract.core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/IStringItem.java (1)
67-69: Verify impact on implementing classes and update accordingly.The addition of the
normalizeSpace()method to theIStringIteminterface is a breaking change that requires all implementing classes to provide an implementation for this new method.Please ensure that all classes implementing
IStringItemare updated to include an implementation ofnormalizeSpace(). This may include:
- Updating the
StringItemImplclass mentioned in thevalueOfmethod of this interface.- Checking for any other implementations of
IStringItemin the codebase.To assist in identifying affected classes, you can run the following command:
After identifying the affected classes, ensure they all implement the new
normalizeSpace()method.✅ Verification successful
No implementing classes found for
IStringItem.The
IStringIteminterface currently has no implementing classes in the codebase. Therefore, adding thenormalizeSpace()method does not impact any existing implementations.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Find all Java files that implement IStringItem echo "Classes implementing IStringItem:" rg --type java "class\s+\w+\s+implements\s+.*IStringItem" -l # Find all Java files that extend classes implementing IStringItem echo "Classes extending implementations of IStringItem:" rg --type java "class\s+\w+\s+extends\s+(\w+)(?=.*implements.*IStringItem)" -l | xargs -I {} rg --type java "class\s+\w+\s+extends\s+{}" -lLength of output: 683
Script:
#!/bin/bash # Step 1: Find all classes that implement IStringItem echo "Classes implementing IStringItem:" implementations=$(rg --type java "class\s+\w+\s+implements\s+.*IStringItem" -l) echo "$implementations" # Step 2: Find all classes that extend the implementations found in Step 1 if [ -n "$implementations" ]; then echo "Classes extending implementations of IStringItem:" for impl in $implementations; do class_name=$(basename "$impl" .java) rg --type java "class\s+\w+\s+extends\s+$class_name" -l done else echo "No classes implement IStringItem." fiLength of output: 263
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/item/atomic/AbstractStringItem.java (1)
11-12: LGTM: Appropriate import and well-defined regex patterns.The addition of the
Patternimport and the declaration of regex patterns for whitespace normalization are well-implemented. The patterns are correctly defined for trimming start, end, and middle whitespaces.Also applies to: 18-21
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java (4)
1-8: LGTM: File structure and package declaration are correct.The file structure, including the SPDX license header, package declaration, and import statement, follows best practices and Java naming conventions.
10-15: LGTM: Class declaration and inheritance are well-defined.The class
RegularExpressionMetapathExceptionis correctly declared as public, extends the appropriate superclass, and includes a serialVersionUID. The naming convention follows Java best practices.
56-95: LGTM: Constructors are well-implemented and documented.The three constructors provide flexibility in creating exception instances with varying levels of detail. They are properly documented with Javadoc comments and correctly call the superclass constructors.
97-101: LGTM: getCodePrefix method is correctly implemented.The
getCodePrefixmethod is properly overridden and returns the expected prefix "MPRX" for this exception type.core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FunctionTestBase.java (1)
100-100: Consider the implications of changing method visibility to public.The
executeFunctionmethod's visibility has been changed fromprivatetopublic. While this change allows for greater reusability of the test utility across different test classes, it's important to consider the following:
- Increased visibility may lead to tighter coupling between test classes if not managed carefully.
- Ensure that this change aligns with the overall testing strategy and doesn't compromise test isolation.
- If the intention is to use this method in other test classes, consider adding appropriate documentation to guide its usage.
To ensure this change doesn't introduce unintended usage, let's check for any new usages of this method outside the current class:
✅ Verification successful
Verified: The
executeFunctionmethod is appropriately used by other test classes, ensuring enhanced reusability without unintended side effects.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usages of executeFunction method outside FunctionTestBase class rg --type java -g '!FunctionTestBase.java' 'FunctionTestBase\.executeFunction'Length of output: 798
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java (1)
Line range hint
1-290: Overall, the changes look good and meet the PR objectives.The implementation of
matches()andtokenize()functions aligns with the XPath specifications and enhances the Metapath library's functionality. The code organization is maintained, and the new functions are properly integrated into the existing structure.A few minor suggestions for improvement:
- Add brief comments explaining the different versions of both
matchesandtokenizefunctions.- Clarify the purpose and behavior of the one-argument version of
tokenize, as it's not typically defined in the XPath specification.These changes successfully address issues #134 and #135, implementing the required functionality for the Metapath processor.
core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java (1)
1-4: License header is appropriate and follows project conventionsThe file starts with the correct SPDX license header, adhering to the project's licensing requirements.
core/src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatchesTest.java (1)
35-125: Comprehensive and Well-Structured Unit TestsThe
FnMatchesTestclass provides a thorough set of unit tests for thefn:matchesfunction, covering various scenarios including positive matches, negative matches, flags usage, and exception handling for invalid patterns and flags. The use of parameterized tests with@ParameterizedTestand@MethodSourceenhances test scalability and maintainability. Binding the$poemvariable in the dynamic context is a good approach for reusability across multiple test cases.core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java (2)
112-114: Ensure the default pattern and input handling comply with the specificationWhen the
tokenizefunction is called with only theinputargument, the default pattern should be\s+(one or more whitespace characters), and the input should not be normalized usingnormalizeSpace(). According to the XPath 3.1 specification, the function should split the input string based on whitespace without modifying the input.
100-115: Remove unnecessary suppression ofPMD.OnlyOneReturnwarningsThe method
executeOneArgcurrently suppresses thePMD.OnlyOneReturnwarning. Refactoring the method to have a single return statement can enhance readability and eliminate the need for suppression.
...nist/secauto/metaschema/core/metapath/function/regex/RegularExpressionMetapathException.java
Show resolved
Hide resolved
.../java/gov/nist/secauto/metaschema/core/metapath/function/library/DefaultFunctionLibrary.java
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/regex/RegexUtil.java
Outdated
Show resolved
Hide resolved
...src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java
Outdated
Show resolved
Hide resolved
...src/test/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenizeTest.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnMatches.java
Outdated
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java
Show resolved
Hide resolved
core/src/main/java/gov/nist/secauto/metaschema/core/metapath/function/library/FnTokenize.java
Outdated
Show resolved
Hide resolved
47b391b to
0423718
Compare
0423718 to
77d8f9f
Compare
77d8f9f to
cc7c378
Compare
64c630d
into
metaschema-framework:develop
Committer Notes
Adds support for the Metapath string functions that handle regular expression operations.
matches()is not implemented in Metapath processor #134fn:replacetokenize()is not implemented in Metapath processor #135Resolves #134
Resolves #135
All Submissions:
By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.
Changes to Core Features: