highly recommend taking a look at libraries, because I don't think maintaining a map of the fields is gonna be a good long term solution, it puts us back to needing dev intervention for schema changes, we should be able to either maintain OG file order, which would be the computationally least complex solution I think, I had looked into this a month or two ago and had a partial solution using either https://github.com/elliotchance/orderedmap or some similar solution main...163-revise-fields-in-random-order-after-revision

#163

^The original issue.

also here is where we are sorting alphabetically,

highly recommend taking a look at libraries, because I don't think maintaining a map of the fields is gonna be a good long term solution, it puts us back to needing dev intervention for schema changes, we should be able to either maintain OG file order, which would be the computationally least complex solution I think, I had looked into this a month or two ago and had a partial solution using either https://github.com/elliotchance/orderedmap or some similar solution main...163-revise-fields-in-random-order-after-revision

also here is where we are sorting alphabetically,

go-oscal/src/internal/generate/generate.go

Line 167 in 6b94a90

slices.Sort(keys)

, idk if removing this would maintain the schema order, because I think that could depend on the marshal/unmarshalling method as well as the golang map ordering

All great items for context - I don't disagree that maintaining the map fields is not a great long term solution. Removing the sort results in the randomized output result with regards to order. Curious if there is another angle to approach this from - but that may be unnecessary work - the fields in the schema are listed alphabetically.

Overall just wanted to validate marshalling oscal models with fields in a specific order to validate they appear as expected. Generate is an operation that we seldomly run (IE going on 6 months since last OSCAL release). Curious how revise would respond coupled with this.

Overall not a pressing need -> more of an experiment to evaluate.

could we just use the schema order (may need to back fix the doctor command to maintain the schema order), but since the schema is xml derived it may actually make sense they are ordered, [ ] will verify in the xml. In that case we wouldn't need to worry about hardcoding, and could pull the order directly from the schema applicable to the oscal document. thoughts?

Closing pull request as we orient to review metaschema for generation.