129 add a schema validator checker

[medley56]

Summary

This PR implements comprehensive XTCE document validation capabilities for Space
Packet Parser, adding both XSD schema validation and structural validation to help
ensure XTCE documents are correct and will work properly for parsing packets.

Changes Made

Core Validation Implementation

• Added space_packet_parser/xtce/validation.py (441 lines) - Complete
  validation system with:
  • ValidationLevel enum (schema, structure, all)
  • ValidationError and ValidationResult dataclasses for structured error
    reporting
  • validate_xtce() function as main entry point
  • Schema validation against XSD with automatic schema downloading
  • Structural validation for XTCE-specific business rules
  • Reference integrity checking (Parameters, ParameterTypes, Containers)

API Integration

• Updated space_packet_parser/__init__.py - Exported validate_xtce function
  for public API
• Updated space_packet_parser/xtce/__init__.py - Renamed constants:
  • DEFAULT_XTCE_NS_PREFIX → STANDARD_XTCE_NS_PREFIX
  • DEFAULT_XTCE_NSMAP → STANDARD_XTCE_NSMAP

CLI Enhancement

• Updated space_packet_parser/cli.py - Added spp validate command with:
  • File path argument for XTCE documents
  • --level option (schema/structure/all)
  • --timeout option for schema downloads
  • Rich console output with color-coded results
  • Exit codes for CI/CD integration

Improved Namespace Handling

• Enhanced space_packet_parser/xtce/definitions.py - Major improvements to
  namespace awareness:
  • Automatic XTCE namespace detection from XML documents
  • Better handling of documents without namespaces (with warnings)
  • Improved error messages for multiple XTCE namespaces
  • Fixed namespace URI vs prefix handling
  • Added validation warnings for missing XTCE namespaces

Configuration Updates

• Updated pyproject.toml - Added Ruff ignore rule for f-strings in docstrings
• Updated docs/source/users.md - Added comprehensive validation documentation
  with examples

Test Infrastructure

• Added tests/unit/test_xtce/test_validation.py (348 lines) - Comprehensive
  test suite:
  • Schema validation tests (valid/invalid documents)
  • Structural validation tests (reference integrity)
  • Error handling and edge cases
  • Timeout and network error scenarios
• Enhanced tests/unit/test_xtce/test_definitions.py - Added
  validation-related tests
• Updated tests/integration/test_cli.py - Added CLI validation command tests
• Updated tests/conftest.py - Updated constant references

Test Data Improvements

• Fixed XML structure in multiple test files to be valid XTCE:
  • tests/test_data/ctim/ctim_xtce_v1.xml - Fixed namespace and structure issues
  • tests/test_data/test_xtce_no_namespace.xml - Removed namespace for testing
  • Multiple other test files updated with proper namespace declarations

Key Features

1. Schema Validation: Validates against official XTCE XSD schemas with
   automatic downloading
2. Structural Validation: Checks XTCE-specific rules like reference integrity
   and unused elements
3. Flexible API: Support for file paths, Path objects, or ElementTree objects
4. CLI Integration: New spp validate command for easy validation from command
   line
5. Robust Error Reporting: Structured error objects with line numbers and XPath
   locations
6. Namespace Awareness: Improved handling of XML namespaces with automatic
   detection

Test Coverage

• 23+ new test cases covering all validation scenarios
• Integration tests for CLI command
• Error handling and edge case coverage
• Network timeout and error scenarios

[codecov]

Codecov Report

❌ Patch coverage is 93.14079% with 38 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.98%. Comparing base (b42e7ae) to head (249e16a).
⚠️ Report is 24 commits behind head on main.

Files with missing lines	Patch %	Lines
space_packet_parser/xtce/validation.py	85.98%	37 Missing ⚠️
space_packet_parser/xtce/definitions.py	93.75%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #180      +/-   ##
==========================================
- Coverage   94.19%   93.98%   -0.21%     
==========================================
  Files          40       42       +2     
  Lines        2841     3375     +534     
==========================================
+ Hits         2676     3172     +496     
- Misses        165      203      +38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[greglucas]

High-level this looks OK. Some thoughts here:

If you are calling "validate_xtce()", do I really want to have to check the return after it? I'm more used to it raising if it is not valid, and then continuing on if it is. So by calling validate I kind of want you to raise an InvalidXTCEError. That could then contain all of the helpful information and maybe even print out within the message etc. That is a pretty large structural change from this approach, so figured I would put that at the top-level comment.

If you do keep it this current way with a "result" return, would you want to add an ability to make it evaluate as a bool so someone could say if if not validate_xtce() and go into the block that way?

Is there a way to automatically fix any of these suggestions and allow someone to do something on the command line like: --validate --fix which would overwrite or write a new version of the XTCE with the suggested changes/updates? That should be a future ticket, just a thought I had while reviewing this.

[medley56]

You make a great point about raising an exception and that's what I would rather do versus a Boolean behavior. I think I could refactor that pretty easily by building in the result check as part of validate_xtce. If result is invalid, attach the result to an exception and raise it. I'll play around with it. That part is easy compared to all the lxml calls for schema validation.

The big thing is I don't want users to have to run the validator over and over uncovering one error at a time.

[medley56]

@greglucas Here's what's changed since you last reviewed. We're ready for another round.

Infrastructure & Testing Improvements

• Added codecov.yml for test coverage configuration
• Added local XSD to tests/test_data/SpaceSystem.xsd for local validation testing
• Implemented XSD retrieval mocking to prevent DOSing omg.org schema server during tests

XTCE Validation Enhancements

• Added caching mechanism for XSD retrievals to improve validation performance
• Improved error handling in validation.py

CLI & Error Handling

• Improved CLI error handling for common validation scenarios
• Added new integration tests for CLI validation functionality
• Enhanced unit tests for validation edge cases

Documentation

• Updated user documentation with latest validation features, including CLI

[greglucas]

It is getting quite big for me to review now, but overall I think this is OK since it is only validation / one-time-use kinds of things, so I'll put down a few notes after trying it out.

• I'm not sure how much the validate() function will actually be used in practice, but I would have expected raise_on_error=True to be the default. i.e. I can just see someone doing spp.validate_xtce(my_file) ... carry on because it is valid
• If you are including the SpaceSystem.xsd file in the test_data, I wonder if it'd be worthwhile just including it with the actual release too at that point. It is rarely changed and ~300KB, so not the end of the world. There is a lot of caching/downloading logic involved. Doesn't make a huge difference to me either way though.
• I am getting errors saying the xsi header needs to be specified to validate an XTCE document. Is there a way you could validate a given version provided by the user or something like that instead of requiring that to be in the file itself? I realize maybe that isn't valid spec, but seems odd to fail with an error in that case to me too because our files are currently working just fine.
• I like the cli coloring and formating :)