Steve Shanbaum

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve Shanbaum

  • Rank
  1. 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
  2. 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.
  3. 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.
  4. 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 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?
  5. 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, and an online validator at 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 JSON Example 1 {“employees”:[ {“name”:“A”, “email”:“”}, {“name”:“B”, “email”:“”}, {“name”:“C”, “email”:“”} ]} The XML representation of above JSON example is given below. <employees> <employee> <name>A</name> <email></email> </employee> <employee> <name>B</name> <email></email> </employee> <employee> <name>C</name> <email></email> </employee> </employees>
  6. 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!
  7. 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.
  8. 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!
  9. 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", ] } }
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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