Add pydantic-xml model generation, XML schema validation tests, and CI workflow

[Copilot]

Adds a new Gradle task vodmlPydanticGenerate that transforms VO-DML models into Python pydantic-xml classes for XML/JSON serialisation without SQLAlchemy coupling, backed by interoperability tests and a dedicated CI workflow.

XSLT generator — tools/xslt/vo-dml2pydantic.xsl

• Maps objectType/dataType → BaseXmlModel subclasses with element() field descriptors
• enumeration → str, Enum; primitiveType → single-field wrapper
• Reuses binding_setup.xsl and all existing binding/mapping infrastructure
• Safe maxOccurs handling via number()/string comparison (avoids xsd:int() failures on unbounded)

Gradle plugin — VodmlPydanticTask.kt / VodmlGradlePlugin.kt

• New VodmlPydanticTask mirrors VodmlPythonTask, sharing outputPythonDir
• vodmlPydanticGenerate registered alongside existing generation tasks

Python interoperability tests — PydanticInteropTest.py

• SampleModelInteropTest, LifecycleModelInteropTest, SerializationExampleInteropTest: construct the same object graphs as the Java tests, serialise to XML/JSON, write to interoperability/python/, assert round-trip fidelity
• JavaInteropReadTest: reads Java-produced JSON and XML from interoperability/java/, validates structure and field values, and schema-validates each XML against its generated XSD using lxml

# Schema validation is applied to every Java interop XML file read in
def test_sample_xml_schema_valid(self):
    xml_bytes = (self._JAVA_DIR / "sample.xml").read_bytes()
    _validate_xml(xml_bytes, "Sample.vo-dml.xsd", self)

Schema validation of Python-generated XML is deferred until the pending namespace/xsi:type generation fixes land.

Build wiring

• pytestPydantic task depends on both vodmlPydanticGenerate and vodmlSchema (ensures XSD files are present before tests run)
• --junit-xml flag added to the pytest command for CI result ingestion
• pydantic-xml==2.13.1 added to the sample virtualenv pip dependencies

CI — .github/workflows/pydantic-test.yml

Dedicated workflow on push/PR to main. Uses explicit step ordering to work around Gradle composite-build task-dependency limitations (the root build.gradle.kts already notes this constraint):

1. Publish runtime + ivoa base model to Maven Local
2. Run Java sample tests → produces interoperability/java/ fixtures
3. ./gradlew :ivoa:vodmlPydanticGenerate :sample:pytestPydantic
4. Publish JUnit results via EnricoMi/publish-unit-test-result-action

Original prompt

---

This section details on the original issue you should resolve

<issue_title>generate pydantic models</issue_title>
<issue_description> pydantic model generation could be done as a python alternative to that in #8 - however, as pydantic is rather opinionated it is unlikely to produce serialisations that are compatible with the serializations from other languages

see pydantic/pydantic#710</issue_description>

<agent_instructions>start off by creating a plan -do not write code - in the first instance concentrate only on xml and json serialisation.

• create a new task vodmlPydaticGenerate in the gradle plugin and create a new XSLT transformation that will perform the actual generation - the task can use the same output directory as the existing vodmlPythonGenerate task
• create tests for each of the sample models that read the java produced serialisations from the interoperability/java directory and then reserialize those model instances to an interoperability/python directory and then do comparisons between the serialised files as a way of determining how good the code generation is</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@pahjbo can use https://github.com/dapper91/pydantic-xml for the xml support @pahjbo actually https://xsdata-pydantic.readthedocs.io/en/latest/ looks better and with https://sqlmodel.tiangolo.com which is built on SQLAlchemy, it does look like there is some hope for a unified approach.... @pahjbo there is also https://github.com/mr-fatalyst/oxyde

• Fixes generate pydantic models #33

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[github-actions]

Test Results

1 tests  +1   0 ✅ ±0   0s ⏱️ ±0s
1 suites +1   0 💤 ±0 
1 files   +1   0 ❌ ±0   1 🔥 +1 

For more details on these errors, see this check.

Results for commit ffecc5a. ± Comparison against base commit 61b7b80.

♻️ This comment has been updated with latest results.

[pahjbo]

@copilot add another python test that reads the model instances from the interoperability/java directory and checks for errors

[Copilot]

@copilot add another python test that reads the model instances from the interoperability/java directory and checks for errors

Added JavaInteropReadTest in commit 10f918e. It reads all three Java-produced model files from interoperability/java/ (both .json and .xml) and asserts correctness of the extracted data:

• JSON tests: parse the VODML container format (refs/content), validate names, counts, classifications, coordinate values, filter names, zval lists, and @type discriminators for polymorphic types (Dcont/Econt).
• XML tests: parse the Java JAXB XML using xml.etree.ElementTree, navigating dotted element names and checking xsi:type attributes.
• A guard test (test_java_interop_files_exist) fails fast with a clear message if the Java interop files haven't been produced yet.

Run with: ./gradlew :ivoa:jar :sample:pytestPydantic (the :ivoa:jar prefix is required per AGENTS.md, same as for :sample:test).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud