Phase 3: .NET XSD example standalone (in-language schema resolver)#16
Merged
Conversation
Mirror Phase 1/2: the .NET XSD validation example resolves the official schema itself instead of needing a prior tools/fetch-schema.sh. - New XSD_Validation/dotnet/SchemaResolver.cs: same 3-step convention as the Java/Python resolvers — $FUNDSXML_SCHEMA_DIR (offline/corporate escape hatch) -> .schema-cache/ -> download from the official GitHub release (HttpClient auto-follows the 302; pulls the xmldsig sibling when imported). Kept as a 2nd file in the SAME project (self-contained example), consistent with the Phase 1 Java inline decision; the plan's shared Funds.Common project was dropped — only XsdValidate needs schema resolution (Schematron uses a jar, SignVerify uses keys), so a shared project referenced by non-users would be noise. - XsdValidate.cs uses SchemaResolver.Resolve(); dropped the "run tools/fetch-schema.sh" error path. - CI: new ".NET - XSD validation (in-language schema resolve)" step (cache-hit / $FUNDSXML_SCHEMA_DIR / negative fixture), mirroring the Java and Python steps. - SchematronValidate.cs: SchXslt jar discovery made standalone ($FUNDSXML_SCHXSLT_JAR or the Maven local repo), mirroring the Python reference variant; comments corrected. Fixed pre-existing latent bugs found while building these projects: the XML comments in XsdValidate.csproj, SchematronValidate.csproj and SignVerify.csproj all contained `--` (invalid XML -> MSB4025; those projects could not be built at all). Also corrected the non-existent `SaxonHE 12.5.0` PackageReference in the Schematron reference variant (Saxon-HE-for-.NET 12 ships as SaxonHE12Net* packages; that path stays a clearly-marked unverified reference — Java is the verified Schematron path). Verified locally with `dotnet run`: cold download, cache-hit, $FUNDSXML_SCHEMA_DIR override, negative fixture (exit 1). All .csproj are now well-formed XML. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Phase 3 of 4. The .NET XSD validation example needed the bash
tools/fetch-schema.shto materialise the schema. This makes it resolve the official XSD itself — same convention already shipped for Java (Phase 1) and Python (Phase 2).What changed
XSD_Validation/dotnet/SchemaResolver.cs(new): identical 3-step convention —$FUNDSXML_SCHEMA_DIR(offline/corporate escape hatch) →.schema-cache/→ download from the official GitHub release (HttpClientauto-follows the 302; pulls thexmldsig-core-schema.xsdsibling when imported). Kept as a second file in the same project (self-contained example), consistent with the Phase 1 Java inline decision. The plan's sharedFunds.Commonproject was dropped: onlyXsdValidateneeds schema resolution (Schematron uses a jar, SignVerify uses keys), so a shared project referenced by non-users would be noise.XsdValidate.csusesSchemaResolver.Resolve(); removed therun tools/fetch-schema.shfailure path..NET - XSD validation (in-language schema resolve)step (cache-hit /$FUNDSXML_SCHEMA_DIR/ negative fixture), mirroring the Java & Python steps.SchematronValidate.cs: SchXslt-jar discovery made standalone ($FUNDSXML_SCHXSLT_JARor the Maven local repo), mirroring the Python reference variant.Pre-existing latent bugs fixed (found while building these projects)
XsdValidate.csproj,SchematronValidate.csproj,SignVerify.csprojall contained--→ invalid XML (MSB4025); those projects could not be built at all before this PR.SaxonHE 12.5.0NuGet id. Saxon-HE-for-.NET 12 ships as fragmentedSaxonHE12Net*packages whose id/version/TFM pairing is environment-specific; that path is now clearly marked an unverified reference (the Java Schematron example is the verified, fully standalone path — and the .NET Schematron also needs the SchXslt jar, which has no NuGet distribution). Not in CI.Verification
dotnet run --project XSD_Validation/dotnetverified locally: cold download, cache-hit,$FUNDSXML_SCHEMA_DIRoverride, negative fixture exits 1. All.csprojare now well-formed XML.Phase 4 (CLI
sh+.ps1pair, deletefetch-schema.sh+ remaining.sh, full CI rewrite incl.windows-latestleg) follows as a separate PR off freshmain.🤖 Generated with Claude Code