Yaron [LaserOp]

By that definition, nothing is ever a breaking change. Non-breaking changes mean that if you support the new version, but the other side doesn't, everything still works. You won't "get" the new stuff, but if it worked before the update, it will work after the update. Adding new labels. Adding fields to existing labels. Adding new optional modes/types to enumerated sets (literals/integers with a defined set of values and meanings). When those changes happen, everything still works. If the other side is not compatible (older) then it won't be able to process/use/parse the new data. But it will still be able to process and handle whatever it knew to handle before. You can put a new Host supporting new a new version in place, and all the existing machines will still work. You can put a new machine using a newer version in place, and it will still work with the existing Host and data. This change... makes things that previously worked, stop working, when one side is updated. It doesn't mean the older side won't get to use the new info, or won't know how to process the new data types. It makes the older side not being able to get old data from old labels that it previously knew how to handle. D worked and was valid, now D may not work and be invalid. R worked and was valid, now it's invalid. You turn valid records, into invalid records, merely by upgrading. That's a breaking change. If I update my machine, and it stops working ("breaks"), that's... about the definition of a breaking change. How do you define "breaking change", if a change that caused something that worked before to immediately stops working, without upgrading the other side, isn't "breaking"? Does not being able to receive the exact same data, for the exact same labels, not "affect the ability of hosts and devices to communicate", as per OMAV? The problem will indeed exist even when calling this 4, yes, of course. Since, again, it is a breaking change. But switching to 4 is an indication that things can break. That's the explicit purpose and usage for a major change. If I update a machine that used 3.xx to 4, it won't (it shouldn't) start to talk 4 with other machines/hosts by default. If I update a machine that used 3.12 to 3.13, it will (and it should) talk 3.13 with other machines/hosts by default. Things are supposed to break when switching to 4, that's what it's for. They're not supposed to break between 3.12 and 3.13.

So, again, what am I supposed to do with those D labels? It's valid for me now to send them longer, and it's now and invalid record for the LMS so it should ignore them. (Because, again, the idea was to ignore invalid new labels, not to invalidate active and working ones). This is straight to the Q&A forum once the new version is out. I'm correctly sending valid data which the LMS then correctly and validly ignores, my machine no longer works after a correctly performed upgrade that fits all the requirements of the standard, what should I do?

Yes, and the last time we were actually involved in a live/phone conference about the engraving reference system, and the last time Pinney (from my company) was in a meeting mentioning it, we ended up being told it's not actually relevant for us and we shouldn't do anything with it as an engraver, and were essentially discouraged from keeping up. So, something in the results of the discussion did turn out to appear relevant and I had some comments (to be fair mostly because it was called "Back Engraving Reference", which again opened the "are you sure it means what you say it means?" discussion, the following details are just more thoughts that came out later, since I was looking at it anyway). Was I supposed to not add anything to the discussion, even if I saw something that appeared problematic, because I wasn't at the meeting? Isn't the purpose of these forums, and of you emailing notice about a new DCS draft, to open the discussions not only to the people who were on the meetings? Now, if someone from the 50 people presents on those meetings, would be kind enough to just rough timestamps of when different topics start, and post those short lists when the audio recording are out, that would be great. I'd be very appreciative, I'm sure other people will be greatly appreciative, and I'm sure it will increase the amount of people who listed to (at least part of) the meetings. As-is, again, a few minutes here and there on the forums, I can justify. Hours of listening to the meetings, most of which not directly relative to my job, would (very rightfully) get me some unkind comments from my boss.

Two main things: This is what the standard specified should happen. Making changes to the standard, which ignore explicit specifications in the standard, is... not how Standards work. It can't contradict itself. It can't specify how something is done, then do it in an incompatible way, without and still be a Standard. For the exact same reason that, I expect, the standard was set to say it should be a major version. At the moment I assume about 100% of anything using the DCS uses version 3. And it's possible to add changes to that version 3, and still work with other software using version 3, because all of the changes are additive. If there's a new label that the other device doesn't know, it can just ignore it, and ignoring it is a fine response, because it won't know what to do with it anyway. All the changes are sort of backward compatible. Updating one device/host in a lab to a new version can be ignored if there isn't a new feature needed on the other machines. Version 4, as a major change, means that this is all gone, as I assume was on the change from 2 to 3. If you're not absolutely sure the other machine is 4, you're not supposed to just send the same and know it will all work, sans not getting new stuff. You have to know what major version you're communicating with, for sure, unless there is also an added back-compatible way to check. It's like knowing there's one machine using the DCS and one machine using something else, which has to be configured appropriately. So with a change to 4, it requires manual indication of which protocol to use on what, at least until complete saturation of 4, or unless there's a good detection built-in on 4. There won't be an "The customer just updated our software on the machine, and suddenly it stops working", because the update won't switch automatically to 4. But with 3.13, the standard is very clear, you can't just switch to 3.13, and everything that worked before will still work. It's safe. There is no reason to add "3.13" manual configuration, or anything of the sort. By definition. If the idea is to change how major/minor versions in the standard are handled, I suppose that's fine. I think it's a bad idea, but it's fine, and the committee can certainly decide to do that. But it didn't happen here, the definition of how major/minor versions are handled remained the same. And this is a minor version. So I can just change my line length to 255, and the Host can just fail to parse it, and everyone is working correctly, which is exactly what the definition of the major version is supposed to avoid.

That's almost 8 hours, mostly not relevant for any one individual topic (like this), with no index or rough timestamps of what was discussed when. I really can justify a few question on a forum, to people who were involved, compared to burning an entire workday... So, back to my question, if I now change my software to support 3.13, can I use the new limit of 255 characters for D labels I send on REQ=INF packets? Was the conclusion in the meeting indicating that I should, and if my system stops working in the lab because the LMS can't initialize, that's all fine? Or was it indicating that I shouldn't, but that there also shouldn't be any notice in DCS document letting me know that? Yes, I'm sort of being snarky here, but this is also an entirely honest question, which I do need an answer for, because right now I do limit record length to 80 when sending D records on initialization.

Did the committee discuss how much of a breaking change this is, and decided it doesn't merit a major version change? Or is it just that nobody noticed it's breaking, so the topic never came up? It certainly didn't occur to me in the previous talks, until just now (when I thought I could change the length for D records, and then it hit me that I actually shouldn't since it's breaking). It certainly seems like small and so not a breaking change, before noticing how it would be, I'm guilty of that myself. The case is very simple. It's a breaking change (again, see my example of sending valid and fully compliant INF=REQ packet, that a valid and fully compliant host will suddenly not be able to process correctly). And the standard is explicit about breaking changes. If this is inserted without officially considering it a breaking change, then, as I wrote, at the very least there should be a notice that the record length is still 80 for all cases where the supported version of the receiver is not known. If it's not there, that is surely not because the committee decided it shouldn't be, but because it was missed as an oversight. In any case I certainly agree it's not all on you. Anyone else reading this has an opinion?

Binary data was already not limited, so not a part of this discussion, as it's not talking about it. Paul, the issue with compatibility is very simple: Say I'm now updating my software, on my company's machine, to support 3.13. I now need to send REQ=INI to a VCA Host. I have more than 80 characters of labels to send in the D records (already the case in some labs). What do I do in the REQ=INI packet? If I send more than 80 characters, and the Host doesn't support 3.13, it's entirely fine for it to consider what I sent it to be an error. It could fail with an error, or ignore some of the labels sent, and possible cut one in the middle and assume I mean a different label. And this is for an existing label, not a new one for 3.13 that it would be otherwise justified to ignore. Clearly sending more than 80 is, in this case, a breaking change. Both sides are technically in 100% compliance to the standard, doing exactly what they're supposed to and allowed to do, and things (that were already working) break after my (bug free and correctly working) software update. Do I not send over 80, even though I'm technically allowed to? If so, again, the DCS has to be explicitly clear that the 80 character limit has to be maintained whenever talking to machine/host that isn't known to be supporting of 3.13. That requires a change to the document which is bigger than just the number. And, again, this is essentially saying in the standard that the change is breaking and so backward compatibility has to be maintained, which means that, again, it contradicts the requirement for minor version. This one is doable and workable, and possibly much simpler to pass than making this a major version change, but it's "ugly". I completely agree that the max length limit needs to extend/go. But you're maintaining a standard, and this is how this standard states that it handles breaking changes, and this is a breaking change, so it has to be addressed.

This is a continuation of a few related topics that were previously discussed in emails (involving Me, Paul, Christian Laurent, and Robert Shanbaum), and mentioned on the last VEW meeting. Since there are potential interested (and contributing) people outside of the email thread, it seems better to transfer this to the forum, so it will be possible for other members to view, and contribute, to the discussion. Apart from #1 I don't have personal stakes in the matter, except for the confusion that can follow from #2, which at this point is solved for me outside of the DCS document. So answers/discussion on #1 are needed, it's an open topic. For the rest I think it's a good idea and important to handle, but they were possible discussed on VEW, so if everyone else is happy... 1. Engraving Reference for front side engraving All of the above was for back-side engraving/marking. What about front side? I strongly believe it couldn't be ER as-is, since there should be only one ER per lens in concept, it shouldn't change based on whether it's wanted for front or back (and it's not even possible to always tailor it even if a VCA Host wanted to). On the other hand, so far in practice from our customers, whenever front-side/finishing engraving isn't done relative to frame (which it usually is, so doesn't matter so much), they expect it relative to FB. But from Christian, they report to use the PRP (Reference Point OC) as center for marking on the front side on a finishing block. (So difference of FBOC__ ) So there are at least two different practices already in practice, and none of them actually says "Engraving" for when describing their Reference Point. There should be an explicit decision in the DCS. Is there to be a different new Reference Point? Should it be standardized on OC (and so the description of OC should mention it explicitly, or it should be mentioned explicitly in Marking Records)? Something else? 2. The new BE Reference Point, name The new BE point ("Back Engraving Reference") is intended to be found from inspecting marks already engraved on the back side, and for PRP / OC to be derived from it. So I think the name and description is currently incorrect and very confusing. "Engraving Reference" very much signals, on clean reading, it's going to be the reference point for engraving, not that it's a different reference point to be gleamed from engraving. 3. The new BE Reference Point, not commutative with other Reference Points, so should it be one or a different record? So far the list of Reference Points are, to my understanding (?), commutative. SBBC__ + BCOC__ = SBOC__ , etc... This would work even for connection labels not officially on the standard, I assume, so probably various LMS/VCA-hosts would be happy to "calculate" one if asked for. But BE doesn't, because it's only useful to find OC, and required the additional BEOCA beyond the normal UP/IN sets for all other Reference Points. Since the usage, and potential errors, are very different from other Reference Points, maybe it shouldn't be on the list as a Reference Point? Or at least there should be something very clear in the definition to separate it. Alternately, maybe I'm just wrong about the assumption of commutativity? Is FBSGIN - BCSGIN + BCOCIN = FBOCIN ? And SBSGIN - BCSGIN + BCOCIN = SBOCIN ? And so then FBSGIN - BCSGIN - SBBCIN is the correct equivalent of FBSBIN ? If yes, then it's a really really strong case that BE (or whatever it should be renamed to) should be differentiated from the Reference Points lists. It's a lone position that doesn't fit and doesn't behave like the rest. If no (probably since SB and FB aren't on a parallel plane, so "- BCSGIN + BCOCIN" isn't valid from one starting position), then there is already a big problem, and which label is valid in which case is very much not clear from the list of Reference Points. So the Reference Points themselves have to be clearly and explicitly split into the different sets/groups, to it will be possible to get from the DCS which can't, and which can't, be connected.

Mark, I'm not sure what you're referring to? Currently (pre 3.13) the only labels without the record length limit of 80 characters are ZZ, WW, PP. The records for all other labels, when using ASCII format, have the 80 characters limit. (Now to either have the max record length change to 255, or to have the max record length removed and replaced by having the max record value length changed to 255, a decision that is apparently still open) There are (again, pre 3.13) no fields that go without that limit, that I noticed. Text fields are explicitly limited to max length of 80, and the other types of fields are shorter. What fields are you thinking of that already go (rather than "could potentially go if it was allowed in the standard") beyond 80 characters? Paul, Which raises another few smaller points: There are multiple other places in the document which mention that the records do/don't adhere to the 80 characters record limit. Of course if that limit is increased, all of these need to change. Either to the new value instead of 80, or just to mention the record length limit without the number (which should be fine, since the record length is already defined elsewhere). For the labels that don't have to follow this limit, and therefore have a non-limited length, it would probably be clearer to explicitly clarify it means that they don't have a length limit, instead of just mentioning that they don't need to match the record length limit. It's not technically necessary, but could avoid some potential confusion. The max length of the text field, and the max length of the record (or of record value), are two separate things. Seems that the intent is to change them together, from the same previous 80 to the same new 255, but these are two different max length changes of two different, and only partially related, things. Personally I do think/agree the max length should be increased on both, but these are still two changes, not one change.

So, A couple of things: 1. What is the length of: Yes, I also assumed there would be something like "record value", but it's indeed not defined. It wasn't needed previously, since the length limit of 80 was for the entire record (line). Which made sense, it had a reason (being able to see full line on text/terminal screen, or matching printers). The new limit is... arbitrary, in both intent and size limit. While I really think the length limit should have just been waived, that isn't what happened, so need to do the best with what we have. In this case, then, I think a direct extension of the length from as it was before (still full record length) will be easier/simpler/straight-forward to modify to instead. Just change "80" to "255" for "record length" (5.1.8), and that's that. Or possibly also still extend text field data, as is already in the draft. Either way it removes the need to add a definition of "record value", since the exact same logic/semantics apply, only the number changed. 2. Length increase is a breaking change: Something additional just occurred to me, which may complicate things more than intended. Increased length is inherently incompatible with anything that expects a limited length. Which means: While it seems silly, this may require a major version change (to 4.00) rather than a minor one (to 3.13). As the OMAV definition states "A change to the major identifier shall occur when changes to the interface occur which could affect the ability of hosts and devices to communicate. Changes to the minor version identifier shall occur ... should not affect the ability of hosts and devices to communicate". If a machine, or host, will receive an already known/supported label, with a longer record length, without expecting it, they might (I'd like to assume realistically won't, but technically they're allowed to) not be able to process it. (e.g. labels like R or A or D records, where a series of multiple labels are there as a block to compensate for record length limit). This also means that the record length of 80 has to be maintained in cases where the supported OMAV is unknown. For example, during initialization, when devices send D records to hosts, they don't know if the host will support longer lengths. It also means that if machines don't send OMAV, then hosts should still always adhere to the shorter length. Actually, come to think of it, during initialization machines can (should, I'd think) send OMAV, but the host doesn't send its own OMAV back, so machines can never rely on it. Maybe it's also a good idea to have the host send OMAV back during initialization, to the minimum of it's own version and what it received from the machine? A bit of a different topic, but seems extra relevant with this. Personally I'd change OMAV during initialization to "must", for both sides, but that may be overkill for now.

Paul, just to verify, when you wrote here "field" length here did you mean "record" length? Or was that decided to be a "field" length limit, so a record with multiple fields could be longer (e.g. a chiral record would have max line length of 16+1+255+1+255) ?

This is indeed much more elegant and efficient (well, it's not yet converted to VCA records format stylistically, but in concept). Not sure it's a good idea to assume, by definition, that both sides will be mirrored always (and I see no theoretical issue with adding to the new label a side field), but beyond that it seems good. But... the only problem it solves is the amount of values (radii and possibly angles) transferred in TRCFMT (the other listed problem of generating splines is the same problem. Not necessary at all to do anything beyond straight lines when there are enough of them) . Which is... not a problem, I'd think. Why is that a practical issue, that requires modifying the standard with a new label and format? Storage space, and communication time, are negligible even for an exceedingly high amount of points/radii. If it was all starting today, this seems better than how TRCFMT does it, and I like it more and appreciate the elegance. But since TRCFMT already exists...