Steve Shanbaum

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve Shanbaum

  • Rank
    Member
  1. 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.
  2. 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. 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>
  4. 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!
  5. 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.
  6. 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!
  7. 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", ] } }
  8. I've updated the working definition, which is still using the same file location as before. https://docs.google.com/document/d/1W9JL-d93RfKZwRp_2K1hBtD27-PhyVI6_-WZjZdrKF4/edit?usp=sharing 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.
  9. 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.
  10. 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.
  11. 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. https://docs.google.com/document/d/1W9JL-d93RfKZwRp_2K1hBtD27-PhyVI6_-WZjZdrKF4/edit?usp=sharing 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.
  12. 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
  13. 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.
  14. 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?