XSD (XML Schema Definition) parser and Go/C/Java/Rust/TypeScript code generator

Last update: Jan 1, 2023

Comments: 17

xgen

Introduction

xgen is a library written in pure Go providing a set of functions that allow you to parse XSD (XML schema definition) files. This library needs Go version 1.10 or later. The full API docs can be seen using go's built-in documentation tool, or online at go.dev.

xgen commands automatically compiles XML schema files into the multi-language type or class declarations code.

Install the command line tool first.

go get -u -v github.com/xuri/xgen/cmd/...

The command below will walk on the xsd path and generate Go language struct code under the output directory.

$ xgen -i /path/to/your/xsd -o /path/to/your/output -l Go

Usage:

$ xgen [<flag> ...] <XSD file or directory> ...
   -i <path> Input file path or directory for the XML schema definition
   -o <path> Output file path or directory for the generated code
   -p        Specify the package name
   -l        Specify the language of generated code (Go/C/Java/Rust/TypeScript)
   -h        Output this help and exit
   -v        Output version and exit

XSD (XML Schema Definition)

XSD, a recommendation of the World Wide Web Consortium (W3C), specifies how to formally describe the elements in an Extensible Markup Language (XML) document. It can be used by programmers to verify each piece of item content in a document. They can check if it adheres to the description of the element it is placed in.

XSD can be used to express a set of rules to which an XML document must conform in order to be considered "valid" according to that schema. However, unlike most other schema languages, XSD was also designed with the intent that determination of a document's validity would produce a collection of information adhering to specific data types. Such a post-validation infoset can be useful in the development of XML document processing software.

Contributing

Contributions are welcome! Open a pull request to fix a bug, or open an issue to discuss a new feature or change. XSD is compliant with XML Schema Part 1: Structures Second Edition.

Licenses

This program is under the terms of the BSD 3-Clause License. See https://opensource.org/licenses/BSD-3-Clause.

Logo is designed by xuri. Licensed under the Creative Commons 3.0 Attributions license.

Owner

Happy coding

https://github.com/xuri/xgen

Comments

Add Support for xsd:choice plurality
PR Details

This adds support for xsd:choice plurality. All elements contained in a xsd:choice now get to be plural if either the element or the containing choice are plural.

Fixes #38.

Description

This adds handling of xsd:choice. It supports choices being enclosed within other choices in order to properly set the plurality of elements. All cases are relatively simple since singular elements get upgraded to plural as soon as one of its containing choice elements is declared as plural or the element itself is plural.

Related Issue

Motivation and Context

I have an xsd that uses choices to basically state that there are multiple occurrences where each occurrence can be of any one type enclosed in that choice. Because xgen doesn't generate any validation code, the only information required to be propagated to the generated code is the correct plurality.

How Has This Been Tested

Added coverage in the base64.xsd, updated the base64.xml example and made sure all tests are passing. Furthermore, I ran xgen on my own real-world use-case and made sure that the generated code would marshal/unmarshal the real-world XML correctly.

Types of changes

[ ] Docs change / refactoring / dependency upgrade

[ ] Bug fix (non-breaking change which fixes an issue)

[x] New feature (non-breaking change which adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.

[ ] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[x] I have read the CONTRIBUTING document.

[x] I have added tests to cover my changes.

[x] All new and existing tests passed.
Add Support for XSD Extensions
PR Details

This builds on the work from @BatmanAoD in https://github.com/xuri/xgen/pull/18 (thanks again for doing all that work!) but also considers the case where an extension is used to extend another type. I was motivated by having this very case in one of the XSD I'm working with but I also wanted to support the case described in issue #7.

Description

I can't say this PR is complete because I'm not sure how to implement the feature in the C version. Are there any references/links on typical libs that C programmers would use to generate XML from their structs? I've implemented the feature in the other languages (Typescript, Java, Rust and Go) with my main interest/expertise being in the Go one but I could use guidance to complete the work on the C variant.

Some details regarding the case of extending a complex type:

Go: The generated code uses struct embedding. the base64 example has been modified to include both supported extension cases and the tests were modified to show the new expected output.

Rust: Children types extending a parent type use flattening. There's no concept of embedding as far as I could tell (I don't know much about Rust) but the flattening should work fine to serialize/deserialize correctly even if there's an extra level in the code to access "inherited" fields.

Java: Uses classic inheritance.

TypeScript: Similar as the Java version, it uses inheritance.

To make development easier, I updated the parser tests to assert on the content of the expected output rather than just the length. This made it easier to view the differences and I actually started with what the desired expected output should be before the implementation.

Related Issue

This fixes issue #7 although it covers the other common case for extensions (extending other complex types).

Motivation and Context

Currently, XSD extensions aren't supported. I'm not sure how generally commonly used they are but I have one use case with the Microsoft ShowPlan XSD that uses extensions heavily to define elements and attributes in base types that are then extended in children types.

How Has This Been Tested

Added to the base64.xsd example to showcase the simple cases and ran through a more complex real-world example where I used the generated go structs and then parsed some real XML for that matching xsd.

Types of changes

[ ] Docs change / refactoring / dependency upgrade

[ ] Bug fix (non-breaking change which fixes an issue)

[x] New feature (non-breaking change which adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.

[ ] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[x] I have read the CONTRIBUTING document.

[x] I have added tests to cover my changes.

[x] All new and existing tests passed.
Fix for #28: Attribute Enumeration Parsing Aborted Prematurely When Enclosed in ComplexType
PR Details

This fixes the parsing of attributes defined with enumerations and enclosed in complex types. Before the change proposed here, attributes of a complex type that were defined with enumerations would render without a type (in go, that meant interface{}) and other attributes in that enclosing complex types would be missing. Issue #28 has an example of this and this PR includes a new type that is an example of this.

Description

This is my first contribution so I'm just getting familiar with the code base but it looks like the problem was that the attribute was prematurely added to the enclosing complex type in the attribute start instead of in the end. This had the side-effect of clearing the attribute from the stack and improperly including the restriction and enumeration data enclosed in the attribute when present.

To fix this, I moved that logic to add the attribute to the parent type in the EndAttribute. For the example added to base64.xsd, this looks correct.

Related Issue

https://github.com/xuri/xgen/issues/28

Motivation and Context

This fixes one issue I was having with generating go structs from a somewhat complex (but valid) XSD. The main problem was that a lot of fields were missing in types that included enumerations but also, as stated earlier, the type for the attribute was incorrectly erased and generated as interface{}.

How Has This Been Tested

I ran the test on the modified base64.xsd and validated that it looks correct. I then updated the expected generated code to ensure the tests would pass.

Note that some expected results for tests in https://github.com/xuri/xsd need to be updated because they were affected by the bug and had incorrect expectations that need to be changed:

maven.apache.org/fml-1.0.1.xsd

fml-1.0.xsd

xdoc-2.0.xsd

Question: I didn't see anything in the contribution guidelines regarding tests in https://github.com/xuri/xsd for which the expected output needed to be changed as part of a bugfix. Should I open a parallel PR in https://github.com/xuri/xsd to update those?

Types of changes

[ ] Docs change / refactoring / dependency upgrade

[x] Bug fix (non-breaking change which fixes an issue)

[ ] New feature (non-breaking change which adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.

[ ] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[x] I have read the CONTRIBUTING document.

[x] I have added tests to cover my changes.

[ ] All new and existing tests passed.
Generate `Value` field for types that use XSD's `extension` element
Description

A suggested fix for #7. I am leaving it as a "draft" for now due to the following issues:

There are some unrelated changes

The branch name does not include the issue number

Only Go, TS, and C code-gen are modified; Rust and Java still need to be updated

Related Issue

#7

Motivation and Context

This is needed for XSD files that use complexType with any character-data.

How Has This Been Tested

I updated the base64.xsd file to ensure that all types are included in a sampe XML generated with http://xsd2xml.com/. I also added a sixth type that is more similar to the example in #7. I then updated the "reference" code-generation files to match my expected output and ensured that the tests still pass.

Types of changes

[ ] Docs change / refactoring / dependency upgrade

[x] Bug fix (non-breaking change which fixes an issue)

[x] New feature (non-breaking change which adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to change)

It's kind of a toss-up whether this is a bug or a new feature.

Checklist

[x] My code follows the code style of this project.

[x] My change requires a change to the documentation.

We should indicate that the Value field contains the character data for complex types.

[ ] I have updated the documentation accordingly.

I can do this if the approach I've proposed is acceptable.

[x] I have read the CONTRIBUTING document.

[x] I have added tests to cover my changes.

[x] All new and existing tests passed.
Go: `gDay` cannot be parsed as `time.Time`

Description

The XSD gDay type is not a timestamp but a recurring calendar day. Valid values given as examples in RELAX NG by Eric van der Vlist are:

---01, ---01Z, ---01+02:00, ---01-04:00, ---15, and ---31

To reproduce the issue:

Generate schema for xsd file with gDay type (such as test/xsd/base64.xsd)

Describe the results you received:

The Go type used in the generated schema to deserialize gDay elements is time.Time

Describe the results you expected:

The Go type used can be deserialized from a valid gDay string, such as the examples above

Wrong Element genetarion

I'm trying to generate a struct for the bellow element but the result wasn't the expected. Element

<xs:element name="infNFe" maxOccurs="unbounded">
<!-- Other elements-->
<xs:element name="PIN" minOccurs="0">
	<xs:annotation>
		<xs:documentation>PIN SUFRAMA</xs:documentation>
		<xs:documentation>PIN atribuído pela SUFRAMA para a operação.</xs:documentation>
	</xs:annotation>
	<xs:simpleType>
		<xs:restriction base="xs:string">
			<xs:whiteSpace value="preserve"/>
			<xs:minLength value="2"/>
			<xs:maxLength value="9"/>
			<xs:pattern value="[1-9]{1}[0-9]{1,8}"/>
		</xs:restriction>
	</xs:simpleType>
</xs:element>
</xs:element>

Generated code :

// InfNFe ...
type InfNFe struct {
	XMLName	xml.Name	`xml:"infNFe"`
	Chave	string	`xml:"chave"`
	PIN	*PIN	`xml:"PIN"`
	DPrev	string	`xml:"dPrev"`
	InfUnidCarga	[]*TUnidCarga	`xml:"infUnidCarga"`
	InfUnidTransp	[]*TUnidadeTransp	`xml:"infUnidTransp"`
}

Expected result:

// InfNFe ...
type InfNFe struct {
	XMLName	xml.Name	`xml:"infNFe"`
	Chave	string	`xml:"chave"`
	PIN	*string	`xml:"PIN"`
	DPrev	string	`xml:"dPrev"`
	InfUnidCarga	[]*TUnidCarga	`xml:"infUnidCarga"`
	InfUnidTransp	[]*TUnidadeTransp	`xml:"infUnidTransp"`
}

Output of go version:

go version go1.14.2 windows/amd64

Environment details (OS, physical, etc.):

windows 10 64bits

Generated code does not generate field for simple value

Description

I have a (simplified) XSD as follows (partial but functional example):

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="attribute">
        <xs:complexType>
            <xs:simpleContent>
                <xs:extension base="xs:string">
                    <xs:attribute type="xs:string" name="origin" use="required"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
    </xs:element>
</xs:schema>

The XML that goes with it would look like this:

<?xml version="1.0" encoding="utf-8"?>
<attribute origin="reqavp">Destination-Host</attribute>

(I confirmed my XSD is valid and would produce the desired XML structure by copying it into http://xsd2xml.com/)

But the Go struct generated by xgen looks as follows:

// Copyright 2020 The xgen Authors. All rights reserved.
//
// DO NOT EDIT: generated by xgen XSD generator
//
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

package schema

import (
	"encoding/xml"
)

// Attribute ...
type Attribute struct {
	XMLName    xml.Name `xml:"attribute"`
	OriginAttr string   `xml:"origin,attr"`
}

There is no field where I can put the 'value' (Destination-Host) of the attribute tag.

Is my XSD invalid, can I edit it to have the expected 'value' field, or is this an issue in the generator? I'm expecting a struct like:

type Attribute struct {
	XMLName    xml.Name `xml:"attribute"`
	OriginAttr string   `xml:"origin,attr"`
	Value      string   `xml:",chardata"`
}

Is there also a way to mark a struct field as xml:",cdata" ? Or will this involve editing the generated code?

xsd:byte should be int8 instead of byte in Go
When parsing the "xsd:byte" tag, it parses byte. Byte is unsigned in go, so it should be int8 (signed instead).

Steps to reproduce the issue:

Have an xsd with a byte tag

try to convert to struct

Describe the results you received: struct with byte Describe the results you expected: struct with int8 Output of go version: go version go1.18 linux/amd64 xgen version or commit ID: 98e2a901798bddb93c5e532c98afc1f5f139d47e

Child element omitted if attribute with enumeration is passed

Description

I've tried to boil it down to the simplest example. I have an XSD as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="template">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="requests"/>
        <xs:element minOccurs="0" ref="responses"/>
      </xs:sequence>
      <xs:attribute name="type" use="required">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="avp"/>
            <xs:enumeration value="condition"/>
            <xs:enumeration value="routing"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:element name="requests" />
  <xs:element name="responses" />
</xs:schema>

After generating, the following is generated:

// Code generated by xgen. DO NOT EDIT.

package schema

import (
	"encoding/xml"
)

// Template ...
type Template struct {
	XMLName  xml.Name    `xml:"template"`
	TypeAttr interface{} `xml:"type,attr"`
	Requests *Requests   `xml:"requests"`
	Template string      `xml:"template"`
}

// Requests ...
type Requests *Requests

// Responses ...
type Responses *Responses

This is missing the Responses key in the Template struct, but adds a Template string property from.. somewhere.

Removing the <xs:simpleType> segment:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="template">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="requests" />
        <xs:element minOccurs="0" ref="responses" />
      </xs:sequence>
      <xs:attribute name="type" use="required" />
    </xs:complexType>
  </xs:element>
  <xs:element name="requests" />
  <xs:element name="responses" />
</xs:schema>

results in a struct that looks more correct:

// Template ...
type Template struct {
	XMLName   xml.Name    `xml:"template"`
	TypeAttr  interface{} `xml:"type,attr"`
	Requests  *Requests   `xml:"requests"`
	Responses *Responses  `xml:"responses"`
}

// Requests ...
type Requests *Requests

// Responses ...
type Responses *Responses

Output of go version:

go version go1.16.2 darwin/amd64

xgen version or commit ID:

v0.0.0-20210301142127-04f2cd700cdb

Environment details (OS, physical, etc.): MacOS, physical

Array is generated althought minOccurs = 1 and maxOccurs = 1

Description

When the xsd file has an element with minOccurs="1" and maxOccurs="1", an array of elements if generated although in this case just a single element would be appropriate.

Steps to reproduce the issue:

Use for example the following xsd file

<?xml version="1.0" encoding="utf-8"?>
<xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="SomeXmlFile">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="SomeElement" type="string" minOccurs="1" maxOccurs="1"  />
        <xsd:element name="SomeOtherElement"  type="string" minOccurs="1" maxOccurs="1" />
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Run xgen -i test.xsd -o test -l Go

Describe the results you received: The generated Go file contains:

 // Code generated by xgen. DO NOT EDIT.
package schema

// SomeXmlFile ...
type SomeXmlFile struct {
  SomeElement      []string `xml:"SomeElement"`
  SomeOtherElement []string `xml:"SomeOtherElement"`
}

Describe the results you expected:

 // Code generated by xgen. DO NOT EDIT.
package schema

// SomeXmlFile ...
type SomeXmlFile struct {
  SomeElement      string `xml:"SomeElement"`
  SomeOtherElement string `xml:"SomeOtherElement"`
}

Testing instructions
Testing instructions, etc

Description

I took the paragraph on testing in the existing CONTRIBUTING.md and separated it into its own section, then added some details.

I also checked in the go.mod changes created by running go test, as well as the generated go.sum file, since xgen is an executable rather than a module.

Finally, I added data/ to .gitignore to facilitate changing the "active" test set without accidentally duplicating it under version control.

Related Issue

Resolves #9.

Motivation and Context

Specific instructions for running tests help potential new contributors.

How Has This Been Tested

I was able to run the parser tests on the base64.xsd input using the instructions I added.

Types of changes

[x] Docs change / refactoring / dependency upgrade

[ ] Bug fix (non-breaking change which fixes an issue)

[ ] New feature (non-breaking change which adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] My code follows the code style of this project.

[ ] My change requires a change to the documentation.

[x] I have updated the documentation accordingly.

[x] I have read the CONTRIBUTING document.

[ ] I have added tests to cover my changes.

[x] All new and existing tests passed.

obix xsd breaks xgen

obix xsd breaks xgen

Steps to reproduce the issue:

Use the obix xsd

<?xml version="1.0" encoding="UTF-8"?>
<!--
     OBIX Version 1.1
     Committee Specification 01
     14 September 2015
     Copyright (c) OASIS Open 2015. All Rights Reserved.
     Source: http://docs.oasis-open.org/obix/obix/v1.1/cs01/schemas/
-->
<xs:schema xmlns="http://docs.oasis-open.org/obix/ns/201506" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://docs.oasis-open.org/obix/ns/201506" elementFormDefault="qualified" id="obix">
	<!-- Simple Types
     ===================== -->
	<xs:simpleType name="status">
		<xs:annotation>
			<xs:documentation>The status Facet is used to annotate an Object about the quality and state of the information.</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:string">
			<xs:enumeration value="disabled"/>
			<xs:enumeration value="fault"/>
			<xs:enumeration value="down"/>
			<xs:enumeration value="unackedAlarm"/>
			<xs:enumeration value="alarm"/>
			<xs:enumeration value="unacked"/>
			<xs:enumeration value="overridden"/>
			<xs:enumeration value="ok"/>
			<!-- ordered by priority -->
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="contractList">
		<xs:annotation>
			<xs:documentation> A sequence of Contracts referenced by an OBIX Object describing the Contracts which the Object implements. A Contract is a template, defined as an OBIX Object, that is referenced by other Objects by using the URI to the Contract Definition. Each Contract Elements is a URI. In XSD, it is a string because the collection of URIs follows special serialization rules, i.e., URIs are space separated, and the zero length list is specified as "nil", See the specification for details.</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:string"/>
	</xs:simpleType>
	<!-- Complex Types
     ===================== -->
	<xs:complexType name="Obj">
		<xs:annotation>
			<xs:documentation>Obj is the common base Object type, from which the other object types are derived.</xs:documentation>
		</xs:annotation>
		<xs:sequence>
			<xs:element ref="obj" minOccurs="0" maxOccurs="unbounded"/>
			<!-- Note to Reviewers:
				The element below was defined in 1.0 and is now removed.
				See note above for details. We recommend new development use namespaces instead.
			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
			-->
		</xs:sequence>
		<xs:attribute ref="display"/>
		<xs:attribute ref="displayName"/>
		<xs:attribute ref="href"/>
		<xs:attribute ref="icon"/>
		<xs:attribute ref="is"/>
		<xs:attribute ref="name"/>
		<xs:attribute ref="null"/>
		<xs:attribute ref="status" default="ok"/>
		<xs:attribute ref="ts"/>
		<xs:attribute ref="writable" default="false"/>
	</xs:complexType>
	<xs:complexType name="AbsTime">
		<xs:annotation>
			<xs:documentation>The abstime type is used to represent an absolute point in time. Its val attribute maps to xs:dateTime, with the exception that it MUST contain the timezone.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:dateTime"/>
				<xs:attribute name="max" type="xs:dateTime"/>
				<xs:attribute name="val" type="xs:dateTime"/>
				<xs:attribute ref="tz"/>
			</xs:extension>
			<!-- obix 1.1 -->
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Bool">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute ref="range"/>
				<xs:attribute name="val" type="xs:boolean" default="false"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Err">
		<xs:complexContent>
			<xs:extension base="Obj"/>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Enum">
		<xs:annotation>
			<xs:documentation>The enum type is used to represent a value which must match a finite set of values.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute ref="range"/>
				<xs:attribute name="val" type="xs:NMTOKEN"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Feed">
		<xs:annotation>
			<xs:documentation>The feed type is used to define a topic for a Feed of events. Feeds are used with Watches to subscribe to a stream of events such as alarms.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute ref="in" default="obix:Nil"/>
				<xs:attribute ref="of" default="obix:obj"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Int">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:long"/>
				<xs:attribute name="max" type="xs:long"/>
				<xs:attribute ref="unit"/>
				<xs:attribute name="val" type="xs:long" default="0"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="List">
		<xs:annotation>
			<xs:documentation>The list type is a specialized Object type for storing a list of other Objects.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:long"/>
				<xs:attribute name="max" type="xs:long"/>
				<xs:attribute ref="of" default="obix:obj"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Op">
		<xs:annotation>
			<xs:documentation>The op type is used to define an operation. All operations take one input Object as a parameter, and return one Object as an output. The input and output Contracts are defined via the in and out attributes.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute ref="in" default="obix:Nil"/>
				<xs:attribute ref="out" default="obix:Nil"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Real">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:double"/>
				<xs:attribute name="max" type="xs:double"/>
				<xs:attribute ref="precision"/>
				<xs:attribute ref="unit"/>
				<xs:attribute name="val" type="xs:double" default="0"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Ref">
		<xs:annotation>
			<xs:documentation>The ref type is used to create an external reference to another OBIX Object.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj"/>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="RelTime">
		<xs:annotation>
			<xs:documentation>The reltime type is used to represent a relative duration of time.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:duration"/>
				<xs:attribute name="max" type="xs:duration"/>
				<xs:attribute name="val" type="xs:duration" default="PT0S"/>
			</xs:extension>
			<!-- obix 1.1 -->
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Str">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:long"/>
				<xs:attribute name="max" type="xs:long"/>
				<xs:attribute name="val" type="xs:string" default=""/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Uri">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="val" type="xs:anyURI"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<!-- obix 1.1 -->
	<xs:complexType name="Date">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:date"/>
				<xs:attribute name="max" type="xs:date"/>
				<xs:attribute name="val" type="xs:date"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="Time">
		<xs:complexContent>
			<xs:extension base="Obj">
				<xs:attribute name="min" type="xs:time"/>
				<xs:attribute name="max" type="xs:time"/>
				<xs:attribute name="val" type="xs:time"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<!-- Global Attributes
     ===================== -->
	<xs:attribute name="display" type="xs:string">
		<xs:annotation>
			<xs:documentation>provides a localized human readable description of the Object</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="displayName" type="xs:string">
		<xs:annotation>
			<xs:documentation>provides a localized human readable name of the Objec</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="href" type="xs:anyURI">
		<xs:annotation>
			<xs:documentation>href of an Obj. If specified, the root Object MUST have an absolute URI. All other hrefs within an obix document are treated as URI references which may be relative.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="icon" type="xs:anyURI">
		<xs:annotation>
			<xs:documentation>provides a URI reference to a graphical icon which may be used to represent the Object in an user agent</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="in" type="contractList">
		<xs:annotation>
			<xs:documentation>Specifies the input argument type used by this Object.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="is" type="contractList">
		<xs:annotation>
			<xs:documentation>Names the Contract the Object implements.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="name" type="xs:NMTOKEN">
		<xs:annotation>
			<xs:documentation/>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="null" type="xs:boolean">
		<xs:annotation>
			<xs:documentation>Attribute if True indicates that this Object has no value, has not been configured or initialized, or is otherwise not defined. Null is a boolean</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="of" type="contractList">
		<xs:annotation>
			<xs:documentation>Specifies the type of child Objects contained by this Object.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="out" type="contractList">
		<xs:annotation>
			<xs:documentation>Specifies the output argument type used by this Object.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="precision" type="xs:long">
		<xs:annotation>
			<xs:documentation>used to describe the number of decimal places to use for a real value</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="range" type="xs:anyURI">
		<xs:annotation>
			<xs:documentation>used to define the value space of an enumeration. A range attribute is a URI
reference to an obix:Range Object</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="status" type="status">
		<xs:annotation>
			<xs:documentation>used to annotate an Object about the quality and state of the information. Status is a pre-enumerated value as described in the obix Specification.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="ts" type="xs:string">
		<xs:annotation>
			<xs:documentation>ts or tagspace applies a defined semantic tag to this object. The semantic tags are defined by the tagspaces as referenced in the Lobby</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="tz" type="xs:string">
		<xs:annotation>
			<xs:documentation>used to annotate an abstime, date, or time Object with a timezone. The value of a tz attribute is a zoneinfo string identifier, as specified in the IANA Time Zone (ZoneInfo DB) database.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="unit" type="xs:anyURI">
		<xs:annotation>
			<xs:documentation>defines a unit of measurement in the SI Units system.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:attribute name="writable" type="xs:boolean">
		<xs:annotation>
			<xs:documentation>specifies if this Object can be written by the client. If false (the default), then the Object is read-only.</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<!-- Global Elements
     ===================== -->
	<xs:element name="obj" type="Obj">
		<xs:annotation>
			<xs:documentation>conveys an obix Object. The Object is the common base type for the derived types. An Object has  associated properties, called Facets, common to all derived types. </xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="abstime" type="AbsTime" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a representation of an absolute point in time. AbsTime is an xs:dateTime with a mandatory timezone.</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="bool" type="Bool" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a boolean value – true or false</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="enum" type="Enum" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys an enumerated value within a fixed set of choices</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="err" type="Obj" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>Conveys an Err Object. Its actual semantics are context dependent. Typically err Objects SHOULD include a human readable description of the problem via the display attribute.</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="feed" type="Feed" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>Conveys a feed of events. Feeds are used with watches to subscribe to a stream of events such as alarms. Feeds are subscribed via Watches</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="int" type="Int" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys an integer value</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="list" type="List" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a list of other Objects.</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="op" type="Op" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys an operation (Op) type. All operations take one input Object as a parameter, and return one Object as an output. The input and output Contracts are defined via the in and out attributes.</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="real" type="Real" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a floating point value</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="ref" type="Ref" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys an external reference to another obix Object. It is the obix equivalent of the HTML anchor tag.</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="reltime" type="RelTime" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>stores a relative time value (duration or time span)</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="str" type="Str" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a UNICODE string</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="uri" type="Uri" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a Universal Resource Identifier</xs:documentation>
		</xs:annotation>
	</xs:element>
	<!-- obix 1.1 -->
	<xs:element name="date" type="Date" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys a specific date as day, month, and year</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="time" type="Time" substitutionGroup="obj">
		<xs:annotation>
			<xs:documentation>conveys  a time of day in hours, minutes, and seconds. Time values in MUST omit the timezone offset and MUST NOT use the trailing “Z”</xs:documentation>
		</xs:annotation>
	</xs:element>
</xs:schema>

Run xgen ~/go/bin/xgen -i obix-v1.1.xsd -o test -l Go
Be puzzled by the generated go code

Describe the results you received:

Elements overwrite struct types
Elements are defined as a substitution group for obj but are not actually asignable

Describe the results you expected:

compileable code

Output of go version:

go1.18.1

xgen version or commit ID:

v0.0.0-20221130013449-4b677f0df988

xs:union is interpreted wrongly

Description If XSD contains xs:union in type definition, it produces struct that contains both values. As result, XML fails to be parsed Steps to reproduce the issue:

Example XSD:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:simpleType name="integer-or-empty">
    <xs:union memberTypes="xs:integer empty-string" />
  </xs:simpleType>
  <xs:simpleType name="empty-string">
    <xs:restriction base="xs:string">
      <xs:enumeration value="" />
    </xs:restriction>
  </xs:simpleType>
  <xs:element name="NETWORK_ACCESS_URL">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="DomainCensus" maxOccurs="1" minOccurs="0">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:string">
                <xs:attribute type="integer-or-empty" name="AccessCount"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Run following command

xgen -i filename.xsd -o report.go -l Go -p report

Following Go code is generated:

// Code generated by xgen. DO NOT EDIT.

package report

import (
	"encoding/xml"
)

// Integerorempty ...
type Integerorempty struct {
	XMLName     xml.Name `xml:"integer-or-empty"`
	Emptystring *Emptystring
	Integer     int
}

// Emptystring ...
type Emptystring string

// DomainCensus ...
type DomainCensus struct {
	AccessCountAttr *Integerorempty `xml:"AccessCount,attr,omitempty"`
	Value           string          `xml:",chardata"`
}

// NETWORKACCESSURL ...
type NETWORKACCESSURL struct {
	XMLName      xml.Name      `xml:"NETWORK_ACCESS_URL"`
	DomainCensus *DomainCensus `xml:"DomainCensus"`
}

Here is sample XML to parse (report.xml):

<?xml version="1.0" encoding="UTF-8"?>
<NETWORK_ACCESS_URL>
  <DomainCensus AccessCount="149511825">84786</DomainCensus>
</NETWORK_ACCESS_URL>

Test code (file report_test.go):

package report

import (
	"encoding/xml"
	"os"
	"testing"
)

func TestReport(t *testing.T) {
	data, err := os.ReadFile("report.xml")
	if err != nil {
		t.Fatal(err)
	}
	var report NETWORKACCESSURL
	if err := xml.Unmarshal(data, &report); err != nil {
		t.Fatal(err)
	}
}

Describe the results you received: go test produces the following:

--- FAIL: TestReport (0.00s)
    report_test.go:16: cannot unmarshal into report.Integerorempty
FAIL
exit status 1
FAIL	github.com/mpkondrashin/ddan/report/t	0.251s

Describe the results you expected: I have expected to parse file successfully Output of go version:

go version go1.18.3 darwin/amd64

xgen version or commit ID:

xgen version: 0.1.0

Environment details (OS, physical, etc.): MacOS Monterey

Possible solution I have no clue, how to solve it as unions of types are not supported by Golang (not sure about other languages).

What worked for me: Changing Integerorempty to int through whole report.go file (using Search & Replace) fixes this issue

I assume some option to force some types to be substituted as other types would be the solution. See https://github.com/xuri/xgen/issues/10 issue. This option would solve this issue too (interpret xsd "integer" as int, int64 or big.Int as user whats it to)

the generated go file contains a field in a struct that is not in the definition
Description

I'm trying to generate structs for go from the schema provided by Tableau (link below), but I'm getting bad results for this XSD version. For comparison, I'm using c# sourcecode generated with xsd (from mono).

The result structures are different than expected.

Steps to reproduce the issue:

get xsd file from https://help.tableau.com/samples/en-us/rest_api/ts-api_3_17.xsd or use https://gist.github.com/sumia01/f15ee5589f4a020b63bd0e016ebaf5b6#file-ts-api_3_17-xsd

generate output file(s)

xgen -i ts-api_3_17.xsd -o 3.17/schema.go -l Go

compare with reference generated with xsd from Mono (https://www.mono-project.com/docs/getting-started/install). I uploaded it here: https://gist.github.com/sumia01/f551985805e2e84c9a83cee1e9ef59f8

Describe the results you received: In the generated result, there is a Status string in the SiteType struct. https://gist.github.com/sumia01/f15ee5589f4a020b63bd0e016ebaf5b6#file-schema-go-L1511

But it shouldn't be there, see the c# reference: https://gist.github.com/sumia01/f551985805e2e84c9a83cee1e9ef59f8#file-tableau_3_17-cs-L2960

And here is the type definition part from the original xsd, I can't find any reference for status here: https://gist.github.com/sumia01/f15ee5589f4a020b63bd0e016ebaf5b6#file-ts-api_3_17-xsd-L1797

One more strange behaviour found here. If I comment the following part from xsd (https://gist.github.com/sumia01/f15ee5589f4a020b63bd0e016ebaf5b6#file-ts-api_3_17-xsd-L1418)



then it's not generated into the SiteType struct. But I don't understand the connection here.

Describe the results you expected:

I'd like to get the same result as in the c# file

Output of go version:

go version go1.19.3 darwin/arm64

xgen version or commit ID:

xgen version: 0.1.0 commit hash: 45dd37dc6afb5afb6ffd28b6e81b760ec6f7e038

Environment details (OS, physical, etc.):

Darwin Sumi-MacBook-Pro.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103 arm64
Added option to disable XML fields/import when using Go
Description

Generated structs are given an XMLName field + encoding/xml import.

XMLName xml.Name `json:"XMLName"

Sometimes you may not want this, for example when using an XSD just to generate structs for some other application than XML-parsing.

This feature adds a commandline option to omit those fields:

--noxml Don't generate XMLName fields on structs (Go)

Types of changes

[ ] Docs change / refactoring / dependency upgrade

[ ] Bug fix (non-breaking change which fixes an issue)

[X] New feature (non-breaking change which adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to change)

Enums not generated properly in certain circumstances

Description Sometimes, depending on the schema, enums are not generated correctly, or are not generated at all.

Steps to reproduce the issue: Schema:

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:here="http://example.org/" targetNamespace="http://example.org/">

    <element name="TopLevel">
        <complexType>
            <choice minOccurs="1" maxOccurs="unbounded">
                <element name="TShirt" type="here:SizeType" minOccurs="0" />
                <element name="Style" minOccurs="0">
                    <simpleType>
                        <restriction base="string">
                            <enumeration value="Value1" />
                            <enumeration value="Value2" />
                        </restriction>
                    </simpleType>
                </element>
            </choice>
        </complexType>
    </element>

    <simpleType name="SizeType">
        <restriction base="string">
            <enumeration value="Small" />
            <enumeration value="Medium" />
            <enumeration value="Large" />
        </restriction>
    </simpleType>

    <simpleType name="HasNoElements">
        <restriction base="string">
        </restriction>
    </simpleType>

</schema>

Command:

xgen -l TypeScript -i example.xsd

Describe the results you received:

// Code generated by xgen. DO NOT EDIT.

// TopLevel ...
export class TopLevel {
	TShirt: Array<SizeType>;
	Style: string;
}

// Style ...
export type Style = string;

// HasNoElements ...
export enum HasNoElements {
	Value1 = 'Value1',
	Value2 = 'Value2',
	Small = 'Small',
	Medium = 'Medium',
	Large = 'Large',
}

Describe the results you expected:

// Code generated by xgen. DO NOT EDIT.

// TopLevel ...
export class TopLevel {
	TShirt: Array<SizeType>;
	Style: string;
}

// Style ...
export type Style = string;

// SizeType ...
export enum SizeType {
	Small = 'Small',
	Medium = 'Medium',
	Large = 'Large',
}

// HasNoElements ...
export type HasNoElements = string;

Output of go version:

go version go1.18.1 linux/amd64

xgen version or commit ID:

98e2a901798bddb93c5e532c98afc1f5f139d47e

Environment details (OS, physical, etc.):

$ uname -a
Linux cinlogic-xps13 5.15.0-41-generic #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Other Information: If I omit the HasNoElements enum from the schema, the generated code also omits the SizeType enum for some reason:

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:here="http://example.org/" targetNamespace="http://example.org/">

    <element name="TopLevel">
        <complexType>
            <choice minOccurs="1" maxOccurs="unbounded">
                <element name="TShirt" type="here:SizeType" minOccurs="0" />
                <element name="Style" minOccurs="0">
                    <simpleType>
                        <restriction base="string">
                            <enumeration value="Value1" />
                            <enumeration value="Value2" />
                        </restriction>
                    </simpleType>
                </element>
            </choice>
        </complexType>
    </element>

    <simpleType name="SizeType">
        <restriction base="string">
            <enumeration value="Small" />
            <enumeration value="Medium" />
            <enumeration value="Large" />
        </restriction>
    </simpleType>

</schema>

// Code generated by xgen. DO NOT EDIT.

// TopLevel ...
export class TopLevel {
	TShirt: Array<SizeType>;
	Style: string;
}

// Style ...
export type Style = string;

Also...

If I omit the Style element from the top level element, then it works fine:

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:here="http://example.org/" targetNamespace="http://example.org/">

    <element name="TopLevel">
        <complexType>
            <choice minOccurs="1" maxOccurs="unbounded">
                <element name="TShirt" type="here:SizeType" minOccurs="0" />
            </choice>
        </complexType>
    </element>

    <simpleType name="SizeType">
        <restriction base="string">
            <enumeration value="Small" />
            <enumeration value="Medium" />
            <enumeration value="Large" />
        </restriction>
    </simpleType>

</schema>

Output:

// Code generated by xgen. DO NOT EDIT.

// TopLevel ...
export class TopLevel {
	TShirt: string;
}

// SizeType ...
export enum SizeType {
	Small = 'Small',
	Medium = 'Medium',
	Large = 'Large',
}

So there is some interaction involving the top level element I think. Also, I think the order of the elements in the schema seems to have some effect too. There seem to be a lot of factors involved in reproducing this.

configurable TypeScript generators for specific xml parsers

Is your feature request related to a problem? Please describe.

Typescript generation come in very handy when zou try to deal with XML parsing within a typescript project. XML Parsing is typically handled by a library, which then transforms the XML in a particular JSON-like form or gives accessor functions to the data. unfortunatelly xgen generated types cannot be used out of the box for most of the commonly used parsers, without modifying the source of the xsd to typescript converter.

Describe the solution you'd like

Either separate flavours of the typescript parser could be provided or some configurability would be great in order to get type-definitions for the JS-result of common XML-parser.

Additional context For my use case, which was providing type-definitions for the gnucash XSD I was able to slightly modify the source code of the Typescript converter to get a fully typed view of a gnucash-xml, parsed by the fast-xml-parser . The result of the experiment can be seen here: https://github.com/bastiion/gnucash-xml-typescript-experiment/tree/gnucash/src/gnucash/typescript3 The modified branch of xgen can be found here https://github.com/bastiion/xgen/tree/faster-xml-parser-ts

XSD (XML Schema Definition) parser and Go/C/Java/Rust/TypeScript code generator

xgen

Introduction

XSD (XML Schema Definition)

Contributing

Licenses

Owner

Comments

Add Support for xsd:choice plurality

PR Details

Description

Related Issue

Motivation and Context

How Has This Been Tested

Types of changes

Checklist

Add Support for XSD Extensions

PR Details

Description

Related Issue

Motivation and Context

How Has This Been Tested

Types of changes

Checklist

Fix for #28: Attribute Enumeration Parsing Aborted Prematurely When Enclosed in ComplexType

PR Details

Description

Related Issue

Motivation and Context

How Has This Been Tested

Types of changes

Checklist

Generate `Value` field for types that use XSD's `extension` element

Description

Related Issue

Motivation and Context

How Has This Been Tested

Types of changes

Checklist

Go: `gDay` cannot be parsed as `time.Time`

Wrong Element genetarion

Generated code :

Expected result:

Generated code does not generate field for simple value

xsd:byte should be int8 instead of byte in Go

Child element omitted if attribute with enumeration is passed

Array is generated althought minOccurs = 1 and maxOccurs = 1

Testing instructions

Testing instructions, etc

Description

Related Issue

Motivation and Context

How Has This Been Tested

Types of changes

Checklist

obix xsd breaks xgen

xs:union is interpreted wrongly

the generated go file contains a field in a struct that is not in the definition

Added option to disable XML fields/import when using Go

Description

Types of changes

Enums not generated properly in certain circumstances

configurable TypeScript generators for specific xml parsers

Related tags

An online Zig compiler inspired by Go and Rust

CodePlayground is a playground tool for go and rust language.

Go implementation of the Rust `dbg` macro

Go specs implemented as a scripting language in Rust.

A Go implementation of Rust's evmap

Slabmap - Ported from Rust library slabmap

GolangChatroom - Live chatrooms built with Golang, React, and TypeScript with Webpack Hot Reloading

jacobin - A more than minimal JVM written in Go and capable of running Java 11 bytecode.

SampleD - scalable sample collection, routing, and schema evolution

Chaosblade executor for chaos experiments on Java applications

Go types of schema.org ontology

Jennifer is a code generator for Go

General Golang Code Generator

Default godoc generator - make your first steps towards better code documentation

Protocol Buffers to HTTP client code generator/converter

The High Code Framework (low-code for devs)