Steve Shanbaum

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve Shanbaum

  • Rank
  1. In working on the standard with where we'd last left it, we've encountered an issue with the division of certain properties. We have two objects that we'd like to combine in to one. Blank Collection : Groups like lens blanks together, and contains an array of blank IDs. Can optionally point to a Characteristic Family, which, if it does, enforces that all associated blanks share the characteristics contained in the Characteristic Family. Characteristic Family: An object containing the inherent Material, Design, and Treatments for a linked blank collection. What I don't like is the number of steps and amount of description it takes to link a blank to its material or inherent treatments, requiring this extra step of traversing through the blank collection to a characteristic family. I'd like to put the properties that are on the Characteristic Family on the Blank Collection instead, and entirely do away with the Characteristic Family. So that if these properties are present on the Blank Collection, they apply to all associated blanks. I think that would greatly simplify understanding this bit of the standard. For examples - Currently {"Blank Collections": [ { "ID": "BCO-YYY-000001", "Characteristic Family ID": "FAM-YYY-000001", "Label": "SF FF Polymer 1.5 - Hard Coated Pucks", "Blank IDs": [ "BLK-YYY-001", "BLK-YYY-002", "BLK-YYY-003", "BLK-YYY-004", "BLK-YYY-005", "BLK-YYY-006", "BLK-YYY-007", "BLK-YYY-008", "BLK-YYY-009", "BLK-YYY-010", ] } ], "Characteristic Families": [ { "ID": "FAM-YYY-000001", "Material ID": "MAT-YYY-000001", "Design ID": "NA", "Blank Collection IDs": [ "BCO-YYY-000001" ], "Inherent Treatment IDs": [ "TRT-YYY-000001" ], "Required Treatment Types": [] } ] } Proposed {"Blank Collections": [ { "ID": "BCO-YYY-000001", "Material ID": "MAT-YYY-000001", "Design ID": "NA", "Inherent Treatment IDs": [ "TRT-YYY-000001" ], "Required Treatment Types": [], "Label": "SF FF Polymer 1.5 - Hard Coated Pucks", "Blank IDs": [ "BLK-YYY-001", "BLK-YYY-002", "BLK-YYY-003", "BLK-YYY-004", "BLK-YYY-005", "BLK-YYY-006", "BLK-YYY-007", "BLK-YYY-008", "BLK-YYY-009", "BLK-YYY-010", ] } }
  2. I've updated the working definition, which is still using the same file location as before. I've modified it so that some of the naming is more consistent now. A reference to a list of other items defined elsewhere in the document has a name ending with "IDs" A reference to a single item defined elsewhere in the document has a name ending in "ID" The Owner value has been removed from each object, given that the ID now incorporates the owner. Alphabetized fields, to make tracking down missing ones easier (Though I stopped doing Blanks after the first few). Changed the way treatments were included in the Characteristic Family to match how it was done at the product level, with using specific lists indicating requirements such as "Required Treatment IDs" I've also included a diagram of that JSON structure. Each box has three sections that are delimited by a horizontal line The first section indicates the name of the node. If there is more than one line in that top section, it indicates a child object of the parent. The second section is for values that are either the object's ID, or references to another objects ID The third section is for values that are not foreign keys, and are informational about that particular object. I think adding all the lines that would point to Parameters and Treatments would make the document a lot more difficult to read, so I've left those out. But, a name that has "* Parameter ID(s)" or "* Treatment ID(s)" will indeed be referencing objects in those appropriate nodes.
  3. Steve posted the presentation in another thread, so that's a better starting point than this one and the discussion should take place over there.
  4. This is to get the conversation started on Base Curve Charts within the LPDS. (Very condensed and slightly modified) Zeiss presented something similar to the following as a suggested terse method of transmitting the Base Curve Charts. Steve should be able to post the actual presentation to get much better detail to explain this. Add, Sphere, Cyl, Base 0, -9, -4, NA 0, -9, -2, 8 0, -9, 0, 6 0, -6, -4, NA 0, -6, -2, 6 0, -6, 0, 4 Where a -6sph, -2.5cyl would pick a 6 base. Which, at first glance, to fit into JSON tersely, would be something like: “Base Curve Charts” : [ { “ID” : “123”, “Owner ID” : “TVC”, “Adds” : [ “0” : { Spheres : [ “-9” : [ “-4” : “NA”, “-2” : 8, “0” : 6 ], “-6” : [ “-4” : “NA”, “-2” : 6, “0” : 4 ] ] } ] } ] Which, since JSON parsers don't ensure that things get spit out in the same order that they were input in, the readability goes out the window. It also doesn't have to be interpreted into JSON and could be left more in the original format. But, this is just to get conversation going about this.
  5. I took the CZV example and modified it to apply the changes we discussed during the working session. Namely, Having materials appear once with treatments owning the lenses used Adding processing parameter collections Having treatment reference IDs in three arrays to indicate Inherent/Required/Excluded treatments Moving the mandatory flag on the processing parameter to instead be implied in the name of the array the processing parameter appears in Including an example of region exclusivity, with a region override. The document should be valid JSON at this point - I changed the comments to a JSON-acceptable format, so that it would pass through jsonlint.
  6. 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
  7. 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.
  8. 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?
  9. Prior file got sent to the cornfield. LPDS v1.0.json
  10. 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