I have an XSD that I've used as input to the parser. Upon generation of code, it resulted in some struct fields to have name collisions or duplicate names with different associated types.
contains a type called SegmentTemplateType, which has other sub-related types, some of these types have same field names, which through the expansion of types results in duplicate naming, as such:
Notice that initialization appears twice and so as bitstream_switching.
I have taken a bit different approach in handling creating an XML parser based on the XSD case. I have taken the attributes and elements to the aggregate higher level type. As such, it provided an opportunity to explicitly identify parts of the type that belong to attribute and parts that belong to elements. Here is an example of the SegmentTemplateType following such an approach.
I'm not certain yet if the decision to consider "expansion/extension" as base_field the right one, but at the moment, I'm thinking of how to make sure there is no "confusion" or "collision" on the similar naming for various parts of the structure. Hence, I've not stumbled upon a case when collision would occur, but once I have seen the output from the generated effort by the xsd-parser-rs, I realized that it would be at least worthy of mention that such took place. Thus giving you an opportunity to consider such a case with an example.
Side point note, interesting that the various approaches you've taken are the very things that I've stumbled upon while making a parser for DASH media type. Kudos to the great thought process.
Hello,
I have an XSD that I've used as input to the parser. Upon generation of code, it resulted in some struct fields to have name collisions or duplicate names with different associated types.
For example: This XSD -> https://gist.github.com/mlevkov/a9a5f77473668e7d53f64a2b5ee3ccfa
contains a type called
SegmentTemplateType
, which has other sub-related types, some of these types have same field names, which through the expansion of types results in duplicate naming, as such:Notice that
initialization
appears twice and so asbitstream_switching
.I have taken a bit different approach in handling creating an XML parser based on the XSD case. I have taken the attributes and elements to the aggregate higher level type. As such, it provided an opportunity to explicitly identify parts of the type that belong to attribute and parts that belong to elements. Here is an example of the
SegmentTemplateType
following such an approach.a work-in-progress version you can find here: https://gist.github.com/mlevkov/094a3c671b175bba5d0a6511d8c0d348
I'm not certain yet if the decision to consider "expansion/extension" as base_field the right one, but at the moment, I'm thinking of how to make sure there is no "confusion" or "collision" on the similar naming for various parts of the structure. Hence, I've not stumbled upon a case when collision would occur, but once I have seen the output from the generated effort by the
xsd-parser-rs
, I realized that it would be at least worthy of mention that such took place. Thus giving you an opportunity to consider such a case with an example.Side point note, interesting that the various approaches you've taken are the very things that I've stumbled upon while making a parser for DASH media type. Kudos to the great thought process.