Seq Field Formatting

Community Discussion
1

I’ve finally gotten around to making some changes/improvements to the way the formatting codes work for Seq fields. You can play with these changes using the 16.7.6 beta.

The following description was updated on April 21st.

The new scheme is two-dimensional.

The first dimension consists of one general formatting string that can be used for a full display of all levels, followed by a separate formatting string specified for each Seq level. These strings are specified one after another, and separated by pipe characters (‘|’). The first of these would be applied when a full expression of a Seq value is appropriate, while the others would be applied when a partial expression might be more helpful. So the second format string would be applied to Seq values of only one level, the third would be applied to Seq values with two levels, and so on.

And then within each formatting string, one formatting character can be specified for each level within a particular Seq value. The following characters are meaningful.

Character Meaning
x (or X) Exclude this level
n (or N) Include this level as-is
nn (or NN) Multiple n’s can be used to indicate padding
a Convert the number to a lower-case letter
A Convert the number to an upper-case letter
i Convert the number to a lower-case roman numeral
I Convert the number to an upper-case roman numeral

Any other, non-meaningful character will be treated as a literal to be used as a prefix, separator, or suffix, depending on its position.

Note that the first formatting string would generally not exclude any levels, while following ones might well exclude more significant levels, instead relying on context to orient the reader.

Here’s an example of how such codes might appear in a collection template file. (The first value of Seq: specifies the field label. The second value of seq specifies the field type. The formatting codes then follow the colon.)

Seq: <seq: n.a.i|n.|xa.|xxi.>

And here’s how a series of Seq values might appear after formatting using these codes.

Seq as Entered Full Partial
1 1 1.
1.1 1.a a.
1.2 1.b b.
1.2.1 1.b.i i.
1.2.2 1.b.ii ii.

See the knowledge base contained within the beta for an example (and possible improvement to the knowledge base numbering).

I’m interested to hear whether people find this to be useful, and whether anyone would prefer any changes.

Note that these formatting codes can be used when displaying a seq field, but do not affect the appearance of a seq field when editing.

2

Thanks for sharing these improvements to the Seq field formatting! This looks very useful, especially for systems requiring specific enumeration styles beyond standard outlines.

I did some quick testing and was able to successfully replicate Luhmann-style IDs visually using a format like Seq: <seq: nanana>, which is great.

Your note mentions that the formatting currently doesn’t affect the edit field. This highlights something I think would be a powerful enhancement: would it be feasible to have an option where the formatted sequence ID could be directly entered or used in the edit field?

While I tested this with Luhmann’s style (1a1), the ability to enter/use the formatted ID directly would be valuable for any custom sequence format someone might define using your rules – for example, formats like 1.a.i, I-A-1, or others using combinations of numbers, letters, and specific delimiters.

The main benefit would be allowing users to work consistently with their chosen, meaningful representation within the interface and also leverage these formatted IDs directly for filenames. This would be fantastic for filename-based linking strategies, where the choice of delimiter defined in the format string (e.g., using ., -, or no separator at all) becomes crucial for predictability and system compatibility.

I realize this likely adds significant complexity, particularly regarding parsing various formatted inputs back into the underlying numeric sequence and validating the custom logic (especially with codes like padding nn that might not be directly reversible or uniquely mappable).

Just wanted to share this thought as it would significantly increase the flexibility and utility of the Seq field for various organizational methods. Thanks again for the feature!

3

Let me look into this and see what I can do.

Thanks for the feedback.

1 Like
4

Just thinking out loudly regarding the validation: the next character in the Seq. field must not be the same as the previous one, e.g. n.na is valid, but nna is not and so on.

edit: already found an edge case where roman numerals follow letters that would still validate.

5

Try out the latest beta and let me know what you think! It now allows editing of either the original seq value, or the formatted value!