Paul Wade

  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Paul Wade

  • Rank
    Advanced Member
  1. PROCBLK new record + SDFMODE extension

    In response to your three points: 1. We will be polling companies to determine the impact of relaxing the 80 character limit. The consensus at the meeting was similar to yours, that it is probably OK but we will need to check before making the change. 2. & 3. If I understood the committee's intentions correctly, all matching DEV would get A=2;2 and B=2;2. All matching DEV;VEN would get A=3;3 and B=2;2. My impression and belief is that inheritance was an expected benefit of this method. However, it may not be that everyone on the committee was thinking the same in that regard. I suppose we shall see based on this post. An interesting case to consider is that if for some reason you did not want your more specific DEV;VEN to get that overridden value you would have to do something like this: A=1;1 B=1;1 PROCBLK=1;DEV; 1!A=2;2 1!B=2;2 PROCBLK=2;DEV;VEN 2!A=3;3 2!B=1;1 That allows as much overriding and inheritance as one would prefer I think. Does anyone see any pitfalls with this approach? Or have I misinterpreted the inheritance discussions?
  2. PROCBLK new record + SDFMODE extension

    Unless you guys feel further need to discuss I’m reading a consensus here. If I’m understanding the discussion at this stage then I will move forward with adding the proposal the group agreed upon at the meeting to 3.12 as it seems there is further consensus here that the prefix method is “good enough”. Further comments can be collected as part of the review process for 3.12 if necessary. If someone feels that my conclusion is premature please let me know.
  3. PROCBLK new record + SDFMODE extension

    What would be the difference between this and just refactoring PROC to support data sets? I mean, other than requiring more characters ("PROC=" for every line) it would seem to be the same thing and to me is cleaner since it's in keeping with the existing record formats in the standard. We would simply need to indicate that PROC records for data sets must be contiguous. I'm not fan of that solution as I felt the prefix idea from the meeting was clean and very simple but if we're going to go with this sort of approach I would think just tweaking PROC would be a more homogeneous solution.
  4. PROCBLK new record + SDFMODE extension

    You are as astute as always... I almost posted an pre-explanation of why we didn't just do away with the prefix altogether. There was a lengthy discussion about it and your summary of why we kept it is spot on. The convenience factor outweighed terseness. At least I feel that is a fair assessment of the result. For the alternate format you proposed, it seems less clean to me than what we ended up with at the meeting but I'll let others comment. The version above will be put into the 3.12 draft for comment as well. Also, related to 3.12, the SDFMODE/LDPATH proposal has been postponed until a future draft so further work can be done. A revised proposal will be forthcoming.
  5. PROCBLK new record + SDFMODE extension

    Yaron: I wanted to post this follow-up based on our discussions from the DCS meeting today so you'd have a chance to offer your thoughts. Your insight on this proposal was extremely valuable and helped the group avoid taking a wrong path, so thank you very much! To members of the group please feel free to correct me where I've gotten any details of the consensus wrong. The group agreed to essentially adopt a modified version of your prefix label proposal: PROCBLK=Prefix;DEV;[VEN];[MOD];[SN] Where "Prefix" is an integer value. Instead of using "=" as a delimiter for the prefix the group settled on "!" (not already in use, not reserved, unlikely to be strongly desired to be part of a real record label name). By using the prefix the PROCEND record is no longer needed (all [prefix]! records belong to that PROCBLK). Examples of this PROCBLK format that the group came up with during the meeting would look like this: PROCBLK=1;FSG;;; 1!LMATID=70;70 1!_SCSBRD=2.50;2.50 1!_SCSBCCA=0;180 1!GAX=0;0 PROCBLK=2;FSG;SCH;HSC; 2!LMATID=72;72 2!_SCSBRD=2.50;2.50 2!_SCSBCCA=0;180 2!GAX=0;0 The standard will require PROCBLK to precede any prefixed records and that the prefixed records be contiguous. This would be similar to the other dataset definitions. Do you see any issues with this solution?
  6. Current Draft Document

    Here is the current draft of the DCS. Change tracking has been turned on in this document. DCS v3.12_NEW Working_5.docx
  7. VEE 2018 Agenda

    The agenda for the meeting at VEE 2018 has been posted here:
  8. VEE 2018 Agenda

    The agenda for the VEE 2018 meeting has been posted here:
  9. Greetings Colleagues, We are soliciting input from the committee members regarding topics for discussion at VEE. Please reply to this post with a list of items you would like included on the agenda. Thanks! Paul
  10. Here is a link to the audio recording by Daniel during our last call.
  11. Special Groove Rimless OMA File

    I'm posting this question on behalf of David Laing at Silhouette: We have a new collection coming in April that is a drilled rimless with a groove to hold a decorative element and we need special groove width and depth. An example of the current OMA file for this special rimless collection is below. As you can see, it has groove specified in ETYP but has no groove dimensions. 1. I was wondering if you had an example of where GDEPTH and GWIDTH values would be placed in the OMA file? 2. Is there any other data we should include to have a better end result?
  12. Lens Description Standard 2.2

    The poll has been closed. The new version was approved.
  13. Lens Description Standard 2.2

    Attached to this post please find version 2.2 of the Lens Description Standard. After review, please vote accordingly and be sure to post any comments below. From Mike Vitale: The only changes that have been made are listed below. I have highlighted the changes made on page 3. 10 and 27 of the document. Category Literal Abbreviation Filter High Energy Visible HEV Color Violet VIOn In addition I revised the revision paragraph (1.3) to more clearly identify changes in each version since 2.0. This mirrors what we've started doing with the Data Communications Standard. THE DOCUMENT IS LINKED BELOW TVC Lens Description Standard 2.2 Draft_pw.pdf
  14. This is a recording of our web meeting from 12/7/17. Conclusion: We will build the outline based on the combined UML diagram provided by CZV and edited by Essilor. I will update the document on Google Drive with the appropriate changes and the group will reconvene after the holidays.
  15. Hi Everyone, The minutes of the most recent working group have been uploaded to Google Drive: Special thanks to Sebastien Piraube for putting these together. Thanks-P P.S. If you guys would prefer documents like this be uploaded as attachments on the forum instead of put on Google Drive please let me know. I have no preference.