-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Types with restrictions should have Marshal/Unmarshal methods #17
Comments
My concern with this is creating an explosion in the amount of generated code and even the number of types. One feature of the xsd package is that it tries to use the builtin Go types if introducing a new type adds no value (for some definition of "value"). I didn't intend for this package to be used for validation, as that is far more work. But let's give this a try. For some of the restrictions, there are many ways to do this. EnumerationsConsider the following type (taken from w3schools):
Here's what
Here's one possible solution:
Another option mapping to an int:
PatternsThe regular expressions defined by XSD seem pretty close to RE2, used by the AssertionNope. Not worth it. I don't want to link in an xpath implementation just to validate an xml type. Other restrictions:Min/max inclusive/exclusive could be useful, and should be easy enough to implement. The whitespace restriction is necessary, I think, as it changes how a value should be parsed. explicitTimezone? pass :D |
I actually went ahead and did already implement some of these. But I'm still struggling with a few other things related to the MPEG-DASH XSD I mentioned in #16. |
I opened #23 for that |
A possible compromise would be to add constants of all possible values for enumerations (without validation during unmarshalling). That will help with type safety when using these values later on. |
In xsdgen/xsdgen.go, any restrictions on types aren't given special treatment, only a simple comment is added to the resulting type.
This should be changed to proper Mashal/Unmarshal methods so full XML validation is possible.
The text was updated successfully, but these errors were encountered: