Steve Shanbaum

Members
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve Shanbaum

  • Rank
    Newbie
  1. Steve Shanbaum

    PROCBLK new record + SDFMODE extension

    That works for me.
  2. Steve Shanbaum

    PROCBLK new record + SDFMODE extension

    One difference is that it will allow for datasets. A common thread I've heard (outside the forum) is that it's a bit verbose for the task. I'd argue that computers will be able to quickly generate or consume the extra text, but that when a human has to examine the OMA data to determine, for example, why a particular device is receiving a given LMATID, it'd be much faster to search through that text for "LMATID" and run through the results and immediately determine which device-specific line applied. That's as opposed to finding a LMATID line with a particular prefix and move back up to find out what to what PROCBLK that line belongs and getting the device there. Now it may be that's not a use-case that's of great concern to folks, and to help determine if I'm imagining a problem, I've attached three examples LMS files that use the three main recommendations for PROCBLK (or lack of it). So, what's the LMATID for a FSG-OPT-VHZ in each of these files? ProcBlockUniquePrefix.txt DeviceSpecificPrefix.txt ProcBlockRequireContiguous.txt
  3. Steve Shanbaum

    PROCBLK new record + SDFMODE extension

    That's a good point, Yaron. I'm a little torn on this, as it's entirely true that we have a number of other datasets that are necessarily ordered and contiguous. TRCFMT RR= RR= There's value in following that schema. Though, I think there'd be something cleaner about using a special character to indicate belonging to a particular PROCBLK, and the '!' seems handy for this, as I'm not aware of it being in use. PROCBLK=FSG;SCH;HSC !LMATID=70;70 !ETC=1;2 Where there wouldn't have to be any restructuring of the contents of the block, as the line is otherwise correct. Looking, the pipe character is a reserved character, and doesn't currently have a definition when used in a name, so that might be a better alternative if we want to maintain absolute compatibility. One other thing that might combine the best of both worlds - we've been using the tag for PROCBLK to identify an upcoming block...what if we didn't use PROCBLK, but simply had the machine prefix on the tag. FSG;SCH;HSC|LMATID=70;70 FSG;SCH;HSC|ETC=1;2 Pros 1) These device-specific records don't have to be contiguous. 2) Ease of knowing which device a line is targeting. 3) Backwards compatible. Cons 1) More verbose.
  4. Steve Shanbaum

    Lens Blank Groups

    What was throwing me on the blank families discussion was that I had planned a similarly named element, but for a different purpose. The blank group I'd envisioned would hold the elements common to a collection of blanks, such as the material, class (semifinished/finished), and possibly other features like Intrinsic Treatments. But, I do understand the goal of this other blank group now. Maybe it would be good to have both? A shared-characteristic grouping, as well as a product-availability grouping?
  5. Steve Shanbaum

    LPDS Lens Catalogue

    Prior file got sent to the cornfield. LPDS v1.0.json
  6. Steve Shanbaum

    LPDS Lens Catalogue

    That'd be great - I know I'd like to work on that. I started to hash something up while we were at the meeting (this attachment), but any starting point on the actual layout would be good at this point. LPDS v1.0.json