Ballance between strong typing and minimizing breaking changes

[krolli]

Upstream vk.xml format is a moving target that gets expanded over time. Whenever there is a change in its schema, it may potentially lead to breaking changes in the API of this crate. To avoid this happening all the time, a lot of the API is using strings to hold values of fields (attributes or elements). While this works reasonably well in many cases, there are situations where strict type may work better (one example being StringBool, which is string that can only have "true" or "false" in it).

Another issue is that many fields are optional (that is, using Option type) despite being required by the upstream schema. This is because one of the original goals was to be able to parse different versions of vk.xml using same version of the crate, and so required fields which weren't present in past versions are optional so that these older versions can also be parsed. Now, after more than 200 versions of vk.xml have appeared, this doesn't seem like very important goal to keep.

So far, the process of deciding how should various fields be presented through crate API was largely ad-hoc and evolved organically. This has lead to historical inconsistencies in the API. There is also PR #26, where it is not clear whether that is a desired change or not.

I am curious to hear opinions of people who are using this crate for parsing.

• Is more strongly-typed API desired?
• Is ability to parse all past versions of spec relevant, or would it be more desirable to match current version accurately?
• Are API breakages due spec changes an issue?

[MarijnS95]

Regardless of how this pans out on the Rust API side, I feel like requesting upstream to be more explicit about possible values. Most enum-like (and bool-like) attributes have their possible values documented like the new nofeatures attribute, but returnedonly for example (whose name sounds like a bool) does not, as pointed out in #34 (comment).