"sequence" extension - integer encoded but lexicographically-orderable string?

[c-pius]

The sequence extension has the constraint "MUST be a non-empty lexicographically-orderable string"

The sequencetype integer defines the sequence as "string-encoded signed 32-bit Integers". I would assume that this does NOT include leading zeros. E.g., 2 is encoded as "2", 10 is encoded as "10".

Given the assumption about leading zeros is correct, this would conflict the "lexicographically-orderable string" requirement from the sequence. Lexicographically, "2" is greater than "10" => should the "lexicographically-orderable" requirement be removed or reduced to a recommendation?

Maybe I am also off track or over dramatizing, let me know :)

[duglin]

hmmm it does seem a bit inconsistent doesn't it :-) I'm adding this to the call for tomorrow

[duglin]

See: #191 and #291 for history. Let's discuss again next week

[duglin]

After reading the historical issue, I'm pretty sure this was just an oversight and the intent was to allow for INTs to be used w/o leading zeros. I opened #1026 to try to address it.

[BenBeattieHood]

@c-plus when I put the original spec for this together, I'd intended for ints to be zero padded. I felt the spec of 'sequence is a string' coupled with 'sequence is used to order events' implies string-encoded ints need zero padding - but maybe I should've included this explicitly for clarity.

In cases where one has exceeded the zero padding (eg moving from string-encoded 32bit int to string-encord 64bit bigint), I'd expect the 'sequencetype' to show this change.

[duglin]

@BenBeattieHood thanks - I'll comment more in the PR to keep everything in one spot

[jskeet]

In cases where one has exceeded the zero padding (eg moving from string-encoded 32bit int to string-encord 64bit bigint), I'd expect the 'sequencetype' to show this change.

Isn't it a bit odd for a sequencetype to change mid-sequence? I suspect clients might find that hard to work with.

I'd also say that zero-padding is quite brittle, in terms of having to predict the number of zeroes to apply. I think we'll want to revisit this before sequence ends up as a fully-specified context attribute. We may need to do that by mandating support for an integer sequencetype in conformant clients (i.e. if you're going to support v1.1 and sequence, you need to support parsing and formatting integer values where specified by the sequencetype). But that can come later.