DCS version 3.13 draft - PLEASE REVIEW

[Robert Shanbaum]

Hello, everyone.  I hope you are safe and well.

With any luck, you'll find a link on this message to a draft of the proposed version 3.13 of the Data Communications Standard. The first draft posted has a draft ID of 30; if any changes are made, and posted here, the draft ID will be incremented. 

Please download it, review it, and post any questions, comments, or objections on this forum, in this topic.

I do not expect task force meetings to take place at the next Vision Expo West.  We should try to discuss any issues that you may have with the draft on this forum; if it becomes necessary, we can arrange Zoom or GoToMeetings.

I would like to be able to approve this version prior to our next meeting, which I expect to occur at Vision Expo East.

DCS v3.13_DRAFT-030.pdf

[Yaron [LaserOp]]

A few comments, on draft ID 30. None I see as extremely critical, except for the last (which is therefore very much an objection rather than a comment/suggestion/question).

I'm basing this on the Revision History list, assuming anything changed in 3.13 so far is listed there, I did not read through all the document:

 

• Regarding the Revision History itself - I think the revision order (newer on top) is the wrong choice here. This ordering makes sense for thing like blogs and web on-page-updates. But in a part of a closed document older to newer would make more sense to me.
• Literal data - The updated definition (in 3.3 and 5.1.7.8) is a substantial improvement,  and much clearer. That said:
  - 1 - There is some difference between the more general definition in 3.3.2 and the more specific one in 5.1.7.8 . The one significant thing that was done in 5.1.7.8 and I think would be an important addition to 3.3.2 as well, is that all possible values are to be enumerated in the record definition. Maybe change 3.3.2 from "...having permissible values specified in the standard" to something like "...having permissible values enumerated in the standard" ?
  - 2 - Since the standard is now clearer that all values are enumerated, is there a point in specifying maximum length? Especially when 5.1.7.8 both specifies maximum length of 12 and allows the definition of each usage to go beyond 12? This is effectively no length limit when defining a Limited record field (since it is explicitly allowed to override 12), and there is no point in specifying maximum length as an issue for anyone using a Limited record field (if all values are enumerated then specifying length is meaningless, maximum length is always the length of the longest enumerated value).
• Maximum length in the definition of Limited should either be waived completely, or be specified in a way that doesn't allow a record definition to override it. (I'd prefer the former, but either option is better, and internally consistent, compared to the current effectively "there is a maximum length and it can be ignored by everyone")
• Reference Coordinate System for Backside Engraved Lenses - Previous issues with terminology and usage aside, just a quick note that 5.2.3.1 has an internal reference error, I assume to the related Figure 2 below the section, stating "Error! Reference source not found." in the middle of the paragraph.
• Removed New DEFAULT label - The Revision History lists having added a new Label DEFAULT. Which is not actually added anyhwhere in the document. I see that it was there in an earlier draft, so I assume it was decided to drop the label, and it's just the Revision History which needs to be adjusted to match.
• ENGMARK coordinate system - Talked about it in the past, the changed definition of the ENGMARK coordinate system origin is highly problematic. From the previous revision I see that the definition changed from trying to define it on black center to trying to define it on block center, this is irrelevant for the practical objections and has the exact same problem.
  Again, there are plenty of labs who, for quite a lot of years now, rely on the fact that the coordinate source for engraving (using ENGMARK or ENGMASK records) is ER, not SB. (The Reference point for an Engraving operation being the Engraving Reference).
  Engraving is being decentered/offset from the Block center in plenty of labs by using SBBC__ + BCER__ records.
  Using the exact same set of job records, a change from 3.12 to 3.13 should absolutely not cause the engraving to move. It even more certainly should not cause the engraving to move to where the lab does not expect, or want, it to be.
  This definition expansion isn't clarifying things, it's changing things. And in a way that will have clear and significant and unwanted impacts on labs. I absolutely don't see any benefit whatsoever to doing it, just many downsides. Why change the origin of an already widely-in-use label?

 

[SJO]

Hi,

1. A small 'flaw' in my point of view is that the indicated page numbers does not correspond with the pdf page numbers. For example, the page where "1" is written on (FOREWORD) is page 4 of the pdf document.This is sometimes confusing when refferering a page to a colleague or customer.
2. Point 5.12 POWER MAP DATASETS: We recently added the labels M/O/H for the fourth field (5.12.2.4). We may need to add them in DCS 3.13 Standard => @Thomas Zangerle?

I'm glad to see that my remarks about ENGLOC and TOLx/TOLVx have been accepted 🙂

[Yaron [LaserOp]]

@SJO - ENGLOC seems to have not been changed from previous versions, it's still type Literal rather than changed to Literal[;] as you suggested. Are you looking at the same document that has been posted here?

[Paul W.]

8 hours ago, SJO said:

Hi,

1. A small 'flaw' in my point of view is that the indicated page numbers does not correspond with the pdf page numbers. For example, the page where "1" is written on (FOREWORD) is page 4 of the pdf document.This is sometimes confusing when refferering a page to a colleague or customer.

Unfortunately that is just the nature of things.  Typically title pages and tables of content are not numbered so you will end up with discrepancies between the PDF page numbering and the document and TOC page numbers.  As long as the TOC matches the page numbers on the document I hope people can find stuff.  I don't really think that is something we can fix.

[Robert Shanbaum]

Hi, Yaron,

I apologize for being so tardy in replying.  I'll go through your suggestions one-by-one.

1. I'm indifferent to the ordering of the revision history, but since it has been done newest first, it would take some work to revise it.  Do you want to volunteer to do it, if the group approves of of doing it that way?

2.  a) I also like "enumerated" better than "specified"; although it might be possible for only one literal value to be specified for a particular record's field value(s), in which case "enumerated" would be inappropriate.  "Specified" is the more general of the two terms. However, we're splitting hairs here.  "Enumerated" would be OK with me.   b)  We have always tried to enforce a measure of "terseness" in various text features.  Just because a particular requirement can be relaxed when necessary doesn't mean that it's "effectively" a nullity.

3.  Limited is there for a reason (namely, to limit the lengths of certain elements).  My preference is to allow the constraint to be relaxed on an exception basis - if that's actually necessary.  I don't recall why we added the "unless otherwise noted in the record definition."   However, as I wrote earlier,  I don't think that allowing an "override" eliminates its utility when it's not explicitly relaxed.

4.  I'll ask Paul to fix the reference errors (he's still on board for that).

5. Same as (4), Paul will fix the revision history.

6. It was not my intention (or anyone else's, as far as I know) that this revision would change the location of an engraving.  I agree that that is unacceptable.

 

 

[SJO]

Hi Robert,

Seems that my comment about TOL* vs TOLV* has not been adapted; could you double-check please?

Tolerance records TOLADD, TOLCYL, TOLDIA,... on Table A.1a should be IMHO integer values (0;1;9) and not (min|max;). The min|max; are for TOLVADD, TOLVCYL, TOLVDIA,...

There is also a typo for INSMOD, I see two times CCF as possible INSMOD; I think that for convex (anterior) surface, inifinity on axis it should be CXI instead of CCF

Edited October 2, 2020 by SJO
add additional issue CCF-CXI

[Yaron [LaserOp]]

Hi Robert,

Extremely late response on my side as well, I missed your response at the time, sorry about that.

1. At the moment there are only three sections there (3.11, 3.12, 3.13), so the work of reordering (if it's agreed to do so) is just switching around 3.11 and 3.13. While it could be a lot of work in theory, in this case it seems to me to be very little work.

That said, it's very little work, so of course I don't mind doing it myself. Except, I will need the original editable document to do so, not the currently published PDF. And I expect that the concern over compatibility between the editors (Word 365 that the PDF was made with, and my OpenOffice/LibreOffice) and wanting to verify correctness of everything, especially on a document with active change tracking, may cause Paul (or whoever would otherwise do this) a lot more work and concern than doing to quick select>cut>paste operations?

2b. If this was written as a recommendation of maximum length, so recommending terseness, I'd actually fully agree. It's acceptable for a Standard to recommend using short short values without enforcing them. It's even fine to require a maximum length with some specific exclusion criteria (value is made up of words and extending to finish the last word? there are multiple values which are very similar so a few more characters are needed to clarify the differentiation? Something else?). But this is presented as a requirement/specification of maximum length, combined with a complete waiving of that maximum length whenever it is wanted without any specific criteria. "There is no maximum length but it's recommended to limit to X characters" can make perfect sense. "There is a maximum length of X characters unless the length is longer" not so much.3

3. And same point, I agree that allowing for overrides is fine, but that requires specifying explicit cases for the overrides. If the override is completely free and unlimited, then the constraint is meaningless, and should be either waived or re-written as a recommendation. "You must/can't do X unless Y" is fine, except where Y is "you want to" instead of something a lot more specific.

 

 

[Yaron [LaserOp]]

Ah, and one more quick typo. On table A.13 " Process Status (“INF”) Packet ", the table lists the label STATUS as STATUSL .

I don't see it on 3.11 (correctly STATUS), but I do see it on 3.12.