Steve Shanbaum
-
Posts
29 -
Joined
-
Last visited
Posts posted by Steve Shanbaum
-
-
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.
-
Thank you all for all your work over the years to get this standard over the line! As noted in Vision Monday here:
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
-
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.
-
On 9/21/2023 at 4:18 PM, Julian Wake said:
On CCCARR and CCBOWL, moulded lenticular blanks with positive base curves have the carrier and bowl on the front surface. Since the bowl and carrier can be on the front or back surface depending on the design, can we remove the “back” reference in the Blank descriptions?
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.
-
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
-
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
-
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 -
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!
-
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!
-
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.
-
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,.
22 hours ago, Paul Wade said:If you're exchanging data between disparate systems, especially non-persisted data over a network interface (such as web services) where terseness is important, and you're using name/value pairs or simple data structures, then JSON is the clear and obvious choice. On the other hand, if you're exchanging data between database systems using complex data structures in large, persisted data sets, then XML is the clear and obvious choice.
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.
-
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?
-
3 hours ago, Paul Wade said:
I have always been more in favor of using XML for this standard. There are three reasons, in order of increasing importance:
1. XML does not have the idiosyncracy of inconsistent array ordering, which affects JSON. This is currently constraining our design options for base curve chart data and could have the same effect on future development.
2. XML is more human readable than JSON, especially for large, complex documents such as these catalogs. Although we will end up parsing these files with software, people are still going to need to read them for troubleshoooting and support purposes. XML is better suited for that.
3. Using XML will allow us to encode all the rules of the standard in a single XML Schema Document (XSD). This XSD can then be used in most development platforms to automatically generate libraries of code for parsing, writing and validating XML files. There are numerous online document validators that if fed an XSD and a sample instance XML file, they can validate the instance document is properly formatted and follows all the necessary rules. This will enable much faster development and adoption of the standard.
I have not heard any good arguments for using JSON. It mostly seems to be "XML is old and stodgy, JSON is new and fun". I think XML is a much better language for this type of endeavor. We can also always convert from XML to JSON for transmission purposes, but defining things in XML gives us many advantages.
My understanding was that the decision on the language used would not be made until the standard had been fleshed out. I had been pushing my points about XML back when Daniel was still in charge and I recall that we specifically tabled that conversation until we had defined all of the fields. I was not expecting it to be dictated in the standard yet.
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> -
On 10/16/2019 at 8:34 AM, Michael Vitale said:
To the entire LPDS Committee, thank you for all your efforts. This is looking really good. Consensus standards are very important for our industry and this is an excellent representative of the great work that you all do!
3.1 - JSON format - Us JSON the proper format to use for this standard and do we believe all manufacturers will have the technical expertise to write this in JSON? They have historically used a csv format for the LDS and this may be very cumbersome for them.
5.1 - Remove the highlight on Violet
5.2 - Abbreviation List - Did we pull the most resent abbreviation list for this?
5.4 - Materials - How are the LMS systems addressing Trivex? (OP?) We should not have a brand name in there but we may want to find an abbreviation for a 1.530 index lens?
5.5 - Design Styles - We still have progressive lens as a design style. I suggest we also have next to it (power variation) as this is the term that ISO uses and ANSI will have in its upcoming revision. This would also be the same term used for "degressive, office, power boost, etc". Maybe the lens manufacturers could chime in here?
6.1 - Describing Compressed Base Curve Charts - the current wording in the second paragraph is; "The following bottom fragment of a base curve chart is for a known add power, power, with the vertical axis representing the prescription sphere power and the horizontal axis representing the prescription cylinder power." Is the area I have changed the text color correct?
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!
-
On 10/15/2019 at 5:06 PM, Dave Wedwick said:
Section 7.3 for Sag Charts
Rather than have Lines be an array of strings, why not do like:"Lines": [ { "Base": 6, "Add": 1, "Radius": 15, "Angle": 0, "Sag": 3.17 }, { "Base": 6.00, "Add": 1.00, "Radius": 15.00, "Angle": 15, "Sag": 3.56 }, ... ]
No need to multiply by 100 and naming the values gives more clarity.
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.
-
Thanks, Dave.
On 10/15/2019 at 5:06 PM, Dave Wedwick said:Fixes for the example in section 4:
- Use the standard double-quote char everywhere - some non-standard ones are in the example (e.g. “Product IDs” versus "Product IDs")
- "Blank Collections" section - remove the last comma after BLK-YYY-010 since this is the last element in the array
I attached a working file after the fixes above.
Suggestions for consistency:
- Consider renaming UsableDiameter to have a space - same for RightOPC, LeftOPC, RightID, etc. as the convention seems to be space separated names like:
- Capitalize words in the names - change "Owner name" to "Owner Name" and "contact" to "Contact"
Clarity on JSON Arrays
In section 7.3
RFC 7159 says "An array is an ordered sequence of zero or more values." So, something like [1, 2, 3, 4, 5] must always be in that order. If a JSON parser does not maintain that order, then the parser is faulty.
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!
-
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",
]
}
}
DCS 3.14 Draft 003
in DCS Discussion
Posted
Hello all,
Thank you in advance for those who are able to attend the upcoming virtual meeting. Please find attached the version 3 draft of 3.14. I've included tag requests from our past meeting, as well as gone through and added a representation of the TOL/TOLV/INS/LD records, where possible, in new columns on the right side of table A.1, with descriptive sections in A.1.1.7 through A.1.1.10 I do plan on requesting feedback on how we should go about support the rest of the tags that don't have a corresponding non-prefixed tag.
Thank you,
-Steve
Edit: I forgot to mention - if you see the file but are unable to download it, please ensure that you're logged in, as downloads aren't available if you're not logged in.
DCS_v3.14_Draft-003.pdf