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.

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

Better Architectural Approaches #4

Open
Firionus opened this issue May 29, 2023 · 0 comments
Open

Better Architectural Approaches #4

Firionus opened this issue May 29, 2023 · 0 comments

Comments

@Firionus
Copy link
Owner

Firionus commented May 29, 2023

So working with the library as I built it is sometimes pretty cumbersome. Some reasons:

  • Parsing needs lots of context for good error reporting
  • All basic validation, cross-linking, etc. happens in one huge chunk of code

A better way might be:

  • First parse with local validation (probably hand-written, pull-based with quick-xml)
  • Intermediate validation (e.g. uniqueness of names in their containers, etc.)
  • Then do cross-linking of all the referential stuff
  • Intermediate validation
  • Here ends the two-way compat
  • Instantiate templates
  • Final validations

Problem: How to know the file location in later validation steps? -> Either attach a file location to everything, or use roxmltree and attach an original node reference to everything with which we can later retrieve the position. Or stick with the current architecture, but it is one-way only and hard to later extend to be two-way.

Althought it seems like the first step could be done with quick-xml serde-derive, it (probably?) wouldn't support the lenient error handling of opengdtf. I think we'd have to write our own serde or quick-xml code.

But this might come with its own issues. Just wanted to write down that thought.

@Firionus Firionus changed the title Better Architectural Appraoches Better Architectural Approaches May 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant