Steve Shanbaum

Moderators
  • Posts

    28
  • Joined

  • Last visited

Everything posted by Steve Shanbaum

  1. The next step is that we had Zeiss and IOT volunteer to provide an example product in the LPDS format, covering a conventional lens product and a freeform design (respectively). I don't expect there to be a quick transition, and indeed, a lot of folks will continue to use the LDS if it had traditionally met their needs, but there are some types of products that simply can't be described in that format. We also are going to be working on a specification for a hosted utility/solution that the Vision Council can offer which could assist with the transition, and will have that spec prior to the next meeting. The Vision Council press release/email blast and following Vision Monday media release should hopefully get to the right companies, as well as the announcement at the Lens, Lab, and LPT Division meeting at Vision Expo.
  2. Thank you all for all your work over the years to get this standard over the line! As noted in Vision Monday here: https://www.visionmonday.com/technology/article/the-vision-council-unveils-new-forwardlooking-lens-product-description-standard-lpds/?uid=17935027D1A32EA4D3AAA9DA60B0007D The Vision Council has officially announced the release of the LPDS, available on their site here; https://thevisioncouncil.org/members/lens-product-description-standard With the public release, I expect more feedback, questions, and concerns about the use of the standard. This forum remains the primary location for discussing the standard in between our meetings, so please don't hesitate to sign up and post your thoughts. Thank you
  3. I've been reminded that the DCS has CC* and CX* definitions for these fields, depending on if the lenticularized surface is carried on the front or the back of the lens. I will modify the LPDS to accommodate this.
  4. The definition of that field actually comes from the Data Communication Standard, so I'll need to bring up the suggestion of that change over with that group.
  5. Thank you so much, Julian, for these detailed corrections. I have made the following edits: Added SEGTHK to Blanks, and updated the reference in the FAQ. Added ADDU (for Upper Add power) to Blanks, and updated the reference in the FAQ. Added SEGSEP to Layouts, and updated the reference in the FAQ. Added SLBP, CCCARR, and CCBOWL to Blanks. Added IntermediateHt to Layouts. Changed the FAQ to point to Material/Category instead of Material/Code. Layout/MFH from data type DCS.Integer to DCS.Numeric. I've added a ReferenceID to Blanks for the moment, but to confirm its usage, are these codes actually unique at the blank level, or actually higher up on the Product level? The above changes are present in 0.90 of the draft standard that I've attached here, which also includes theming changes to match the current branding of the Vision Council. TVC Lens Product Description Standard 0.90 FAQ.pdf TVC Lens Product Description Standard 0.90.pdf
  6. Edit: Draft 0.90 with additional formatting changes available below. Also, please note that the files will show 'Unavailable' unless you're signed in, so please don't hesitate to create a login so that you'll be able to download the attached documents. Please find attached the 0.89 draft for the Lens Product Description Standard. A change from the prior version is the separation of the FAQ for consumers of the standard, which was previously section 8 within the standard, out to a separate document. As the information contained in the FAQ is to aid with the transfer to the LPDS over from the Lens Description Standard, that information is not necessarily internally relevant to the standard and was separated for that reason. This is the draft version that will be up for discussion at our meeting at Vision Expo West, so please take time in these coming weeks to read through the standard and see if you will have any issues that would prevent its promotion to version 1.0. Thank you, and I look forward to seeing you on at the LPDS meeting on September 27th. TVC Lens Product Description Standard 0.90.pdf TVC Lens Product Description Standard 0.90 FAQ.pdf
  7. Please find attached the 0.88 draft version of the Lens Product Description Standard. The flexible nature of this standard will allow for a single catalog format that both lens blank manufacturers and freeform lens designers are able to use. In the not-too-distant future, it can also serve as a catalog for optical laboratories to describe their lens offering, though that's not the focus of this initial release. Due to the flexibility of the standard, I'm going to add a little expository text here that will hopefully help describe the very high-level usage of the standard. Capitalized words indicate their related objects within the standard. When a blank manufacturer provides a new catalog, they will be including a number of Blanks, which share common features (to reduce duplication) that are grouped by a Blank Collection. It's at the Blank Collection level that characteristics that are common across a large selection of Blanks are stored, such as a shared Material and Design. These Blank Collections are referenced by a Product. Though it may appear that the Product represents needless duplication of the Blank Collection, it enables the use of the standard by lens designers as well. Lens designers will be able to describe a Product, referencing a particular Design that can be applied to a range of Materials, without having to specify the actual Blanks to which the Design can be applied. The consumer of the Standard will be able to know the specifications of that Design, and to which range of lenses it can be applied. Looking down the road, this is the same flexibility that will allow the Standard to be used by a lab to electronically provide a catalog to a retailer, in that the lab can use the Standard to define a set of Products that are orderable, along with the relevant constraints on those products, such as the inclusion or exclusion of particular treatments. This does mean that the way the Standard will be parsed may differ depending on the consumer. An optical lab that is importing technical specifications for a new set of lens blanks will focus on starting from the included Blank Collections. A retailer will be more concerned with what can be ordered from the Product side, and will start the import there. As this is still a draft version, we are looking forward to your feedback on improving the Standard's usability and coverage. Please feel free to comment here with your thoughts after giving the standard a read. As an aside, I would like to thank all the members of the editorial committee over the years (and those who might not be officially on it, but have sure spent time in the meetings at some point). It's truly been a team effort to bring this document to the level that it's at, and I appreciate your time hashing through the topics at our numerous meetings and creating samples and diagrams. My many thanks to: Adrian Blackburn Ron Carey Chris Eustace Marcos Garcia Brent Jacobs Tony LeBlanc Steve Nedomansky Sebastien Piraube Mike Vitale Paul Wade TVC Lens Product Description Standard 0.88.pdf
  8. Thank you all for your input in helping complete version 3.13 of the Data Communication Standard. In preparation for our upcoming meeting in September at Vision Expo West, I'd like to solicit topics for discussion for the next version of the DCS. These may be elements that are in the present document which you've noticed could use clarity in their description, errors that may need correction, or items that are not represented in the current standard but you feel would benefit the industry through their inclusion. You can either email those items to me, so that I can add them to the agenda, or you can post them here in this thread. Thank you!
  9. Hi All, I'm posting v0.84 of the LPDS for your comments, questions, and suggestions. One note is that section 8 will end up living in an accompanying document. It's present at the end of the Standard just to serve as a location in which to manage the content. Please give that section some thought, as I'd like it to cover the frequently asked questions that one may have when attempting to mentally process the Standard. Within a week or two I hope to have a preliminary pass at the LDS to LDPS conversion utility available, so folks can see how a given LDS file would appear, translated into the LPDS format. Thank you for giving this your time, it's greatly appreciated! TVC Lens Product Description Standard 0.84.pdf
  10. Hi Haim, Yes, this will get handled in the standard in the way you show. The current description of the base curve chart line reads as (there are minor changes from your posted example with the naming): The formatting of the compressed base curve chart within the Standard is as follows, using the example chart fragment from 6.1. The Base Curve Chart object has an ID, and an array named ‘Adds’. Adds is an array of objects, where each object contains the base curve chart values for a single add power. The add power that applies is within the range specified between the ‘MinAdd’ and ‘MaxAdd’ values, inclusive. For a single vision, the add power range will be 0.00 to 0.00. The lines for that add power are in the ‘Lines’ array of strings, where each string corresponds to one record in the compressed base curve chart. The sphere, cylinder, and base curve values are all represented as *100. If the fourth and fifth values are not present in a given line (the base curve min and max recommended values), they are presumed to equal the third value.
  11. I'd wager that including a reference to this thread would be a sufficient basis for talking points, so the poll could simply be for picking XML or JSON. Or do you mean allow a forum conversation about it? Because we'll certainly want folks to be able to speak out. I don't know if there'll be an argument of, "Why do we have to pick one at this point," but to that I'd say that there's enough uniqueness to how the information would end up presented between the two formats that the Standard really needs to be specific. Trying to deal with both would just be messy and confusing,. That's just it - Ideally, I'd like the transmission of the payload to be a web-based API for retrieving some new set of products. So that software vendors could point to a manufacturer's or designer's API, retrieve new products in the Standard's format, and be done. Or new items could be presented on a web page, based on a catalog delivered via the Standard. Things are only getting more webby, and I think we'd be missing the mark if we're not targeting making these catalogs available through web services, in addition to passing around files. As for the complexity, though we'll have a lot of repeated elements (multiple products, parameters, etc) and I'd expect an individual payload could be quite large, the actual elements involved are not complex compared to the allowances of XML. I expect any of the complexity in the structure about which someone will have difficulty understanding will most likely be due to the amount of information contained in the Standard, and how the pieces relate to each other. There's not some inherent property of XML that's going to explain how a Blank Item relates to a Product. If we do go with XML, we'll need to determine which properties are elements, and which are attributes of elements, and then explain why they're like that, and make sure that every time we need to add some new property we have that same conversation. The fact that JSON has a more limited set of things it can do simplifies this. You mention that JSON would make more sense for a successor to the DCS, but terseness seems like the only relevant factor there. I would imagine part of a redesign of the DCS would be to expand on its capabilities, and that would likely involve making use of some number of objects in the file. At what number of objects, amount of nesting, or length of file, do you determine that it's simply too complex for JSON and should instead be XML? We save these files out for analysis and can attach them in emails, so the fact that the file can stick around on a hard drive shouldn't be it. But at this point we're rehashing old ground - you're telling me it's obviously the best choice, I'm not seeing the obviousness, and we could likely go around and around until there's some new third option that we both think is trash. I think we just need a poll, get more people in the conversation, and move on.
  12. I'm not too sure about the use case you specify, where it's more readable due to being able to find a closing tag. Is someone going to be scrolling through a list of <Products> until they get to </Products> and have determined much, as opposed to searching for what they're actually interested in? I would expect the main text editors in use in the major OS's out there can format JSON as well as XML. And I'm still not sure we want anyone having to deal with changing much of the payload of this thing directly, in any event. It's likely my own unfamiliarity with XML, but I find his examples at the link you posted seem designed to demonstrate problems with JSON that aren't just problems with JSON. In the example where it's showing a question going from a single correct answer, to being multiple choice, it seems to suggest that for something processing XML to accept the change the only thing you'd have to do is add another element, as opposed to JSON which would switch to an array. Except the processor is going to have to switch in either case to handling the possible answers as an array. And given the 'strict specification' of only having one correct answer before, this really seems designed to make it easy on the XML side by presupposing you'd have a 'correct' attribute on the element already, so that you could more easily slide in a second one with a different value for that attribute because it's presumably already looking at that. Not including my favorite part, which is his closing tags don't match the opening tags, which can obviously happen in XML (not that you couldn't forget a comma or over-include one in JSON). I haven't used a code generator for XML, or XPath, though I can certainly see how both would be handy. I certainly don't want this to be something that slows down the standard from getting used, so if you feel XML's going to cause parties to adopt it more quickly, I'm fine with that. I think a lot of the functionality that's present in one, is present for the other, even if in draft form (where apparently JSON schema has been percolating for 10 years judging from https://datatracker.ietf.org/doc/draft-handrews-json-schema/). And I think anyone that's capable of working with one is capable of working with the other. I don't mind going through the document and switching it to be in XML. Can it just go up for a vote of the group?
  13. 1) Apparently I've been under an incorrect misconception about the ordering issue, as pointed out by Dave. It might be time for me to look for a new parser that doesn't fiddle with things. 2) I'm not really sold on the idea that XML's any more human readable than JSON - in fact all those extra closing tags visually clutters things up for me. 3) There's JSON Schema that corresponds to XML's XSDs, http://json-schema.org/ and an online validator at https://www.jsonschemavalidator.net/ A big reason to use JSON is its brevity, and native ability to handle arrays, of which we're going to have a fair number in the Standard. Nabbed the following example from https://sentai.eu/info/json-vs-xml/ JSON Example 1 {“employees”:[ {“name”:“A”, “email”:“a@a.com”}, {“name”:“B”, “email”:“b@b.com”}, {“name”:“C”, “email”:“c@c.com”} ]} The XML representation of above JSON example is given below. <employees> <employee> <name>A</name> <email>a@a.com</email> </employee> <employee> <name>B</name> <email>b@b.com</email> </employee> <employee> <name>C</name> <email>c@c.com</email> </employee> </employees>
  14. Hi Mike, 3.1 - It'll likely warrant a vote of the group between JSON or XML, given Paul's concerns. I wouldn't want to venture back to CSV, as that's really limiting in terms of extending the standard out in the future to cover currently-unforeseen issues, nor is CSV great for describing this inheritance and relational catalog. But it's definitely not going to be something that could be produced in Excel, which is going to cause some headaches for folks. 5.1 - Done 5.2 - It was pulled from the Lens Description Standard 2.2 - if there's a newer list, please send that along and I'll incorporate it there. 6.1 - Apparently I was worried about it not having enough power. I've removed the excess now. I don't have anything to say about 5.4 and 5.5 yet. Thank you!
  15. The use of the lines done as a single string was simply to compress the amount of space the base curve charts will take up, given the number of records. I'm not entirely opposed to bringing them out to objects instead, but I'd wager that someone looking at interpreting the sag chart will likely be doing so after an import into a system where the information could be presented in a friendlier manner.
  16. Thanks, Dave. Yeah, Word was occasionally throwing in that alternate quotation, I'll have to see what that's about, as it'll cause problems on future updates. I agree with the capitalization changes. For the parser concern, I know I'd personally run in to an issue with a parser not maintaining the order of the array, and thought I'd determined at that time that it was a caveat of using JSON. But, yes, if it's part of the standard, that should be sufficient to warrant having parsers that don't fiddle with the order of the array. Thank you!
  17. 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", ] } }