Field length max size

[The Vision Council]

18 hours ago, Yaron [LaserOp] said:

OK, Paul, since you keep insisting, I listened (well, mostly did quick skips throughout, to locate the relevant section/s) to the recording of the VEW meeting.

Glad you finally listened to a meeting.  Probably the wrong one though.  We discussed that change first at VEE.  It was just the details we were discussing at VEW after having agreed in principle to the change at VEE.  I'm pretty sure the impact was discussed at that first meeting so it wasn't necessary to rehash it at VEW.  At least, that's my recollection.  In any event, thanks for your feedback.  Your objection is noted.  I disagree with your opinion and I have clearly stated my reasons why I believe this is a perfectly valid minor revision change.  No one else has agreed with your position thus far so, once again, we will be going with the consensus which is to include this change in 3.13.

Edit:  To confirm the committee's position, I have created a poll.  We'll go with those results since at this point I don't believe there are any further arguments to make.

[Yaron [LaserOp]]

31 minutes ago, Paul Wade said:

No one else has agreed with your position thus far so, once again, we will be going with the consensus which is to include this change in 3.13.

 

 

I actually read Mark G. comment as essentially agreeing, saying his LMS will keep sending existing labels with 80 character limit, even though that limit is no longer in the standard, in order to ensure that devices will be able to keep working. Just like I was saying devices will similarly need to keep sending relevant labels to 80 to character limit, in order to not cause some Hosts to stop working.

Also, again, the alternative isn't necessarily a major version increase. That one is required if the change is kept as-is, simply increasing the length.

But it's also possible to limit the scope of the size increase, so that nothing will break. The issue is with existing already used labels, where the increase will cause an impact, and won't be expected by older software. Which are, in practice, the multi-record labels (e.g. D, R, A...).

So if the length limit will be kept to 80 on all of those multi-record labels (that don't already have explicit length in their definition), and increased only for single-record labels (which beyond being the majority, are also probably where the increase was wanted, and what the purpose of the increase is for), that solves the problem.

Otherwise, again, as I think Mark practically agreed, the change won't cause a problem because everyone will ignore the change, in a way differing from what the DCS states ("only increase on labels where required" vs "across the board").

[The Vision Council]

You need to make a concise recommendation then.  I don't think anyone is going to be able to follow all of the various points the way they are spread out.  Keep them brief and on topic and I'll include them in the poll.  You seem to be proposing one of the following:

1.  If we are going to increase the length without a restriction on which records it can apply to, then it belongs in 4.0

2.  If we are going to limit it to specific records, such as XSTATUS, then you are fine with it being included in 3.13

Is this correct?  Again, please be concise.

Edit:  May be moot as at least two other members have already voted to postpone until 4.0 so this might get completely tabled until our next meeting.

[Yaron [LaserOp]]

Basically yes. There can be a few other valid (in this case "valid" meaning technically usable to get the wanted result and without breaking anything) options, though probably more complex.

As you request I'll list here briefly, without the reasons/explanations inside the options themselves. If anyone who reads this does have a specific question, and can't find it on this thread, I'll be happy to answer with at least my understanding of what and why I present the option.

Options to increase the record value length (change max length limit from record length of 80 to record-value length of 255), without making breaking changes inside a minor version change:

1. Increase record-value length for everything. Do a major version increase, to 4.0. Devices/hosts that support it should treat accordingly (not changing to 3.13 automatically without manual configuration, while 3.12- systems are still out in the field).
2. Increase only for specific records, which will not change "automatically" (without anyone entering new job data in different ways/formats) anyway if the limit is extended, . XSTATUS, LDPATH, ENGMARK... , as well as all experimental/vendor-specific labels. All other records still limited to 80 record length.
3. Increase only for single-record labels (and all experimental/vendor-specific). All multi-record labels (D, R, A, ZA...) keep the 80 max record length (except for those that already explicitly extend it, nothing changes there)
4. Increase only for single-record labels (...), which have at least one Text field. All other labels keep the 80 max record length (...).
5. Increase only when communicating with something (device/host) that clearly identified itself as supporting 3.13 (e.g. a device that sent OMAV=3.13+ during initialization). Add option during initialization for host to respond with its own supported OMAV. Any records written/sent without this (during initialization, to files, to devices/hosts that didn't report their version) keep the 80 characters record length.

Notice that 1, 2, and 5, are guaranteed to not cause any in-minor-version breaking changes, regardless of usage of any other labels (2 will require some manual work "now" to decide which standard labels are included to begin with, 5 should be robust, and works similar to other like changes in the past such as TXTENC, but therefore makes adopting the change more complicated). 

3 and 4 seem to me to be enough to prevent any breaking changes (by themselves, merely from increasing the length) in practice, at least I wasn't personally able to think of a use cases where a problem will occur with them. And they should be clear to define, and relatively easy to implement. 3 basically excludes what is likely to cause problems, and 4 tries to excludes anything that probably doesn't have a valid reason for "needing" the extension (with its current purpose).

(As an aside, this works "correctly" by being the cause for 4.0 (and delaying the currently planned 4.0 to 5.0). It's not relevant for combining with the current planned 4.0, since that involves a data format change to things like (from my understading) JSON / XML, which already don't have any forced max length limit on most data types, like Text.