Solid

For certain dictionaries (especially in the Philippines, in PLB SFM lexicons) it is important to be able to verify that certain sibling fields are entered in the "correct" order. Otherwise, deviant entries in the published dictionary may not format correct or may be hard to understand.

Solid currently does not care about the ordering of sibling fields, and that's typically ok in most MDF lexicons because those are usually reordered by the MDFormatter anyway. But those who don't reorder, and users of some non-MDF systems, would benefit from checking this, to find where they've deviated from their preferred order.

One way to do this would be to have an "child ordering" setting the user could fill out for a given parent field.
A) For example, given the following settings, if either Gloss or Definition exist, they must be in proper order, and they must come before any Example field.
\sn : child ordering: ge de xv

B) Given the following settings, if either Gloss or Definition exist (in whatever order), they must come before any Example field.
\sn : child ordering: ge|de xv
(where pipe means "or")

Any children not mentioned would be allowed to occur in any order, provided of course, that they didn't violate the hierarchy.

An alternative version of this would be through a setting on each child field indicating which fields it "cannot precede". But I would find that less intuitive and harder to review at a glance.

Here's how the same two examples might look.
A)
\ge : cannot precede:
\de : cannot precede: ge
\xv : cannot precede: de
That is, Solid would enforce this sequence: ge de xv
(even if \de were omitted, \xv should still not be allowed to precede \ge, in my opinion)

B)
\ge : cannot precede:
\de : cannot precede:
\xv : cannot precede: ge de
That is, Solid would enforce this sequence: ge|de xv

Again, I find this less intuitive, although it avoids the problem of having the user type pipes into a field.

Workaround: This can currently be partially simulated by imposing additional hierarchy. By temporarily making Gloss a child of Definition you can enforce that Gloss must come before Definition. But this has the side effect of making Gloss a required field when Definition exists. And making temporary changes like this in a PLB SFM lexicon is tedious since there are so many more distinct fields. (E.g. there are a half dozen subentry fields, whereas MDF only has one, \se.)