[WIP] Generate C# classes from XSD files in TAKconn-DotNet

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

Generate .NET C# classes from the XSD files located in WOT.TAK.Connection/protocol/xml/atak in the TDF-PL/TAKconn-DotNet repository (ref: e9f5b9d). Requirements and acceptance criteria:

Background:

• The folder contains a set of XSD files (a main schema "Marker - Spot.xsd" that uses xs:include to reference event/.xsd and details/.xsd). These XSDs define types used by the project and must be converted to C# classes for use in the library.

Tasks for the coding agent (detailed and actionable):

1. Inspect the XSD files under WOT.TAK.Connection/protocol/xml/atak and resolve includes/imports appropriately. Ensure the generator sees the full schema graph so type references (e.g., event_point, link, contact, color, status, etc.) are resolved.

2. Generate C# classes for the schema graph. Generation details:

   • Target language: C# (produce .cs files)
   • Target framework: .NET Standard / .NET 6 compatible code (no reliance on old .NET Framework-only features). Use XmlSerializer-compatible attributes (System.Xml.Serialization) for elements/attributes and preserve element names.
   • Map schema types to C# types in a natural way (xs:int -> int, xs:decimal -> decimal, xs:dateTime -> DateTime, optional value types -> nullable types where minOccurs=0 etc.).
   • Use a single CLR namespace: WOT.TAK.Connection.Protocol.Xml.Atak.Generated (or similar) so generated files live under that namespace.
   • For complex types that are used as global elements (e.g., event, link, contact), generate both the named type (class) and a global element-decorated wrapper if the chosen generator doesn't produce that by default.
   • Enable partial class generation so future manual additions can be made in partial classes.

3. Add the generated .cs files to the repository under a new folder: WOT.TAK.Connection/protocol/xml/atak/Generated (or under a shared project means). Name files sensibly (Event.cs, Link.cs, Point.cs, Contact.cs, Color.cs, Status.cs, etc.).

4. Add or update a project file (if necessary) so the generated files are included in the build. Prefer to add an MSBuild include in the WOT.TAK.Connection project (or a new shared project) so the classes are compiled. If changing csproj, use globbing (Include="protocol/xml/atak/Generated/**/*.cs") and set where appropriate.

5. Add a README in the Generated folder that documents how the classes were generated (tool used, command-line, generator options) and how to regenerate them locally (e.g., xsd.exe / xsd2code / svcutil or dotnet-xscgen if used). Include the exact command line(s).

6. Validation: include a unit test or small console program under tests/ (or an existing test project) to demonstrate round-trip serialization of the main element (event) to XML and validate that serialized XML validates against the original XSD graph using XmlSchemaSet (use the BaseDirResolver pattern to load the schemas). The test should exercise at least one populated Event object and validate successfully.

7. Ensure no XSD 1.1-only constructs are required by the generator; if any XSD 1.1 constructs exist, add a note in the README explaining any incompatibilities and how they were handled (or that a different generator is required).

8. Avoid duplicate global element declarations: ensure the PR adds only the generated C# files and does not alter the XSD files. The schema-loading code used during generation should avoid adding both the main schema and all included files in a way that causes duplicates.

Deliverables in the PR:

• A new folder WOT.TAK.Connection/protocol/xml/atak/Generated with generated .cs files.
• A README.md in that folder describing the generation method and command(s).
• A small test project or test file demonstrating serialization + schema validation (optional location: WOT.TAK.Connection.Tests/AtakGeneratedTests.cs). If adding a test project, add necessary csproj changes.
• No changes to existing XSD files except if a harmless fix is required to make the XSD 1.0-compatible; such fix must be explained in the PR description.

PR description guidance:

• Explain which tool was used to generate the classes and show the exact command(s).
• Explain any schema fixes performed (if needed) and why.
• Show how to regenerate locally and how to run the demo/test.

Notes for the implementer:

• Use an approach that produces XmlSerializer-friendly types and keeps attributes/elements names identical to the XSD.
• Prefer built-in Microsoft tools (xsd.exe or svcutil) or a well-known generator (xsd2code) that can be run in CI. If using a third-party generator, include instructions for installing/using it in the README.
• Ensure generated code compiles under .NET 6 (or the repo's target framework). If the repo's project targets an older TF, keep compatibility.

Repository to commit changes: TDF-PL/TAKconn-DotNet

Do not set assignees. Please create a single pull request branch and include the changes described above. Provide the PR once done.

This pull request was created as a result of the following prompt from Copilot chat.

Generate .NET C# classes from the XSD files located in WOT.TAK.Connection/protocol/xml/atak in the TDF-PL/TAKconn-DotNet repository (ref: e9f5b9d). Requirements and acceptance criteria:

Background:

• The folder contains a set of XSD files (a main schema "Marker - Spot.xsd" that uses xs:include to reference event/.xsd and details/.xsd). These XSDs define types used by the project and must be converted to C# classes for use in the library.

Tasks for the coding agent (detailed and actionable):

1. Inspect the XSD files under WOT.TAK.Connection/protocol/xml/atak and resolve includes/imports appropriately. Ensure the generator sees the full schema graph so type references (e.g., event_point, link, contact, color, status, etc.) are resolved.

2. Generate C# classes for the schema graph. Generation details:

   • Target language: C# (produce .cs files)
   • Target framework: .NET Standard / .NET 6 compatible code (no reliance on old .NET Framework-only features). Use XmlSerializer-compatible attributes (System.Xml.Serialization) for elements/attributes and preserve element names.
   • Map schema types to C# types in a natural way (xs:int -> int, xs:decimal -> decimal, xs:dateTime -> DateTime, optional value types -> nullable types where minOccurs=0 etc.).
   • Use a single CLR namespace: WOT.TAK.Connection.Protocol.Xml.Atak.Generated (or similar) so generated files live under that namespace.
   • For complex types that are used as global elements (e.g., event, link, contact), generate both the named type (class) and a global element-decorated wrapper if the chosen generator doesn't produce that by default.
   • Enable partial class generation so future manual additions can be made in partial classes.

3. Add the generated .cs files to the repository under a new folder: WOT.TAK.Connection/protocol/xml/atak/Generated (or under a shared project means). Name files sensibly (Event.cs, Link.cs, Point.cs, Contact.cs, Color.cs, Status.cs, etc.).

4. Add or update a project file (if necessary) so the generated files are included in the build. Prefer to add an MSBuild include in the WOT.TAK.Connection project (or a new shared project) so the classes are compiled. If changing csproj, use globbing (Include="protocol/xml/atak/Generated/**/*.cs") and set where appropriate.

5. Add a README in the Generated folder that documents how the classes were generated (tool used, command-line, generator options) and how to regenerate them locally (e.g., xsd.exe / xsd2code / svcutil or dotnet-xscgen if used). Include the exact command line(s).

6. Validation: include a unit test or small console program under tests/ (or an existing test project) to demonstrate round-trip serialization of the main element (event) to XML and validate that serialized XML validates against the original XSD graph using XmlSchemaSet (use the BaseDirResolver pattern to load the schemas). The test should exercise at least one populated Event object and validate successfully.

7. Ensure no XSD 1.1-only constructs are required by the generator; if any XSD 1.1 constructs exist, add a note in the README explaining any incompatibilities and how they were handled (or that a different generator is required).

8. Avoid duplicate global element declarations: ensure the PR adds only the generated C# files and does not alter the XSD files. The schema-loading code used during generation should avoid adding both the main schema and all included files in a way that causes duplicates.

Deliverables in the PR:

• A new folder WOT.TAK.Connection/protocol/xml/atak/Generated with generated .cs files.
• A README.md in that folder describing the generation method and command(s).
• A small test project or test file demonstrating serialization + schema validation (optional location: WOT.TAK.Connection.Tests/AtakGeneratedTests.cs). If adding a test project, add necessary csproj changes.
• No changes to existing XSD files except if a harmless fix is required to make the XSD 1.0-compatible; such fix must be explained in the PR description.

PR description guidance:

• Explain which tool was used to generate the classes and show the exact command(s).
• Explain any schema fixes performed (if needed) and why.
• Show how to regenerate locally and how to run the demo/test.

Notes for the implementer:

• Use an approach that produces XmlSerializer-friendly types and keeps attributes/elements names identical to the XSD.
• Prefer built-in Microsoft tools (xsd.exe or svcutil) or a well-known generator (xsd2code) that can be run in CI. If using a third-party generator, include instructions for installing/using it in the README.
• Ensure generated code compiles under .NET 6 (or the repo's target framework). If the repo's project targets an older TF, keep compatibility.

Repository to commit changes: TDF-PL/TAKconn-DotNet

Do not set assignees. Please create a single pull request branch and include the changes described above. Provide the PR once done.

---

💡 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.