Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide a mechanism for defining schema specific metapath extensions #242

Closed
3 tasks
RS-Credentive opened this issue Sep 21, 2024 · 1 comment · Fixed by #266
Closed
3 tasks

Provide a mechanism for defining schema specific metapath extensions #242

RS-Credentive opened this issue Sep 21, 2024 · 1 comment · Fixed by #266
Labels
enhancement New feature or request

Comments

@RS-Credentive
Copy link

User Story

As a developer of metaschema tooling, I need a mechanism to identify metapath functions that are used in metaschema specifications.

Goals

When a metaschema specification such as OSCAL defines a metapath functions (e.g. "has-oscal-namespace"), metaschema tooling should be able to identify a pure metapath equivalent of the function. Currently, a tool which simply parses the metaschema xsd and a metaschema specification has no way to derive the pure metapath equivalent the metapath function.

Dependencies

No response

Acceptance Criteria

  • All website and readme documentation affected by the changes in this issue have been updated.
  • A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
  • The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

Revisions

No response
@RS-Credentive RS-Credentive added the enhancement New feature or request label Sep 21, 2024
@david-waltermire
Copy link
Contributor

david-waltermire commented Oct 18, 2024 •
edited
Loading

This will require the ability to declare functions, which will require new syntax. Something like what exists in XSLT.

This is something that needs to be implemented in https://github.com/metaschema-framework/metaschema.

@david-waltermire david-waltermire transferred this issue from metaschema-framework/liboscal-java Nov 9, 2024
@david-waltermire david-waltermire mentioned this issue Nov 9, 2024
Merged
6 tasks
@david-waltermire david-waltermire mentioned this issue Nov 26, 2024
Merged
11 tasks
@david-waltermire david-waltermire linked a pull request Nov 26, 2024 that will close this issue
Feature/anonymous functions #266
Merged
11 tasks
david-waltermire added a commit that referenced this issue Dec 2, 2024
@david-waltermire
Feature/anonymous functions (#266)
dff71d3 
* Hooked up the data type specific cast methods using the data type service as the source of data types. This provides for long-term scalability as new data types are added.
* Completed testing eqname and varref cases for the arrow operator. Resolves #68.
* Inline functions are now working. Resolves #242.
* Refactored Metapath expression to use an interface instead of the implementation for returned instances. Updated all uses to use IMetaschemaExpression. Changed uses of evaluateAs using the ResultType.SEQUENCE to just use evaluate. Removed ResultType.SEQUENCE.
* Applied suggestions from code review
david-waltermire added a commit that referenced this issue Dec 4, 2024
@david-waltermire
Metapath implementation refactoring (#271)
7f4fe19 
* Feature/anonymous functions (#266)

* Hooked up the data type specific cast methods using the data type service as the source of data types. This provides for long-term scalability as new data types are added.
* Completed testing eqname and varref cases for the arrow operator. Resolves #68.
* Inline functions are now working. Resolves #242.
* Refactored Metapath expression to use an interface instead of the implementation for returned instances. Updated all uses to use IMetaschemaExpression. Changed uses of evaluateAs using the ResultType.SEQUENCE to just use evaluate. Removed ResultType.SEQUENCE.
* Applied suggestions from code review

* Refactored coded exception to store the prefix. Created sub-exceptions for array handling.

* Added absent dynamic context sub-exception.

* Added sub-exceptions for the DynamicMetapathException. Fixed a bug where root paths were not raising the correct MPDY0050 error when a node was used in the context that did not have a document node ancestor.

* Started refactoring the base of the MetapathException tree to have two branches: StaticMetapathError and DynamicMetapathError. StaticMetapathErrors should be limited to compilation, while DynamicMetapathErrors should be limited to execution.

* Cleaned up Metapath compilation in constraint implementations. Metapaths are now directly compiled at parse time.

* Added support for lazy Metapath compilation. Cleaned up well-known namespace and prefix support, moving this functionality to a new WellKnown class.

* Enabled tests that now work with lazy Metapath compilation.

* Continued to refactor the Metapath runtime exception hierarchy. Created a RuntimeMetapathError exception class that all runtime exceptions are now children of. Moved function-related exceptions to their own branch in the Metapath runtime error tree.

* Package reorganization to align all item related classes in the same package hierarchy. Similar with XML and JSON related classes.

* Added coderabbit config.
@github-project-automation github-project-automation bot moved this from Backlog to Done in Spec and Tooling Work Board Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
Spec and Tooling Work Board
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Feature/anonymous functions david-waltermire/metaschema-java
2 participants
@david-waltermire @RS-Credentive