Add support for sibling sort order for model browsing and BIE editing.

[jim-wilson-kt]

Problem statement

connectSpec users can be overwhelmed by the number of child components a component may have. As connectSpec has grown over the years, components are seemingly in random order (e.g., XParty CC, followed by a bunch of non-party related components, followed by YParty). This complication is exacerbated by type hierarchies dictating component order.

Enhancement request

The numbers in the items listed below are intended exclusively for reference purposes.

1. The context of changing the sort order for this is the model-browsing view (see #1637).
2. Only users in a developer role can reorder siblings.
3. Changes are not tracked or versioned.
4. Updates take immediate effect and are not subject to release.
5. Changes are universal (not per user).
6. The context for viewing the effects of sort order include the BIE editing view and the model-browsing view (see #1637).
7. Changing the sort order does not apply to BIE expressions. (We may want to consider it. But that would be a separate issue.)
8. Changing or viewing the sort order does not apply to CC editing.
9. The sort order is determined by a weight value assigned to ASCCPs sorted in descending order, followed by name (as it would appear in a JSON Schema property name or XML element name) in ascending order.
10. The weight values need not be unique. (E.g., one could have two ASCCPs with weights of 100).
11. The weight values need not be sequential. (E.g., one could have values 10, 20, 30, 75).
12. The current sort order is preserved for XML Schema production (i.e., the order of model-parts within sequence compositors).
13. New components are always added as the last among siblings with respect to XML Schema production.

Note: The current component order only matters in the context of XML Schema production (as far as Jim knows).

General problem statements, users and observers, and high-level use cases available at https://oagi.atlassian.net/wiki/x/FQBtMgE.

[hakjuoh]

@jim-wilson-kt @kbserm i) The requirement for changing the order seems to necessitate the addition of another layer besides CC and BIE. This is because the order information cannot be applied to CC (as it does not imply a change to CC) nor to BIE (as it does not affect BIE expressions).

ii) Additionally, the applied weights are likely to be applied universally across all components in the release. If a weight of 100 is applied to a component, that component will have a weight of 100 consistently across all Trees. This method has the advantage of being intuitive to use, but it has the drawback that the order may become somewhat mixed when components are added or modified (this fact can be observed in the properties and pros/cons of CSS's z-index).

[jim-wilson-kt]

i) I don't understand this. Perhaps we can discuss during the connectCenter Working Group meeting.

ii) It would be OK if were applied universally across all components. For example, I would like to have all ID-related components sorted first and *Party components just after. That would apply anywhere they appear in a BIE view or model browser view.

@hakjuoh: Can you confirm that you have point 6 from the original post in mind with your comments?