The Vision Council

  • Content Count

  • Joined

  • Last visited

  • Days Won


The Vision Council last won the day on July 10 2018

The Vision Council had the most liked content!

Community Reputation

1 Neutral

About The Vision Council

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi All, I was informed today that due to financial challenges related to COVID-19 I'm no longer going to be employed by The Vision Council. Tomorrow 5/6/20 will be my last day. I wanted to say that it's been a pleasure working on these committees with everyone, not just during my time at TVC but even when I was at Signet Armorlite. Going forward please direct inquiries related to the DCS or LPDS Committees to Michael Vitale ( Regards, Paul
  2. Hi All, I was informed today that due to financial challenges related to COVID-19 I'm no longer going to be employed by The Vision Council. Tomorrow 5/6/20 will be my last day. I wanted to say that it's been a pleasure working on these committees with everyone, not just during my time at TVC but even when I was at Signet Armorlite. Going forward please direct inquiries related to the DCS or LPDS Committees to Michael Vitale ( Regards, Paul
  3. Dear Colleagues, I hope all is well with everyone and their families during this worldwide crisis. I've spoken with the Steve's (Steve Nedomansky and Steve Shanbaum) and they'd like to try and make some progress with the draft review despite losing our face-to-face meeting at Vision Expo East. Attached you will find the most recent draft for the committee to review. Please post your feedback and comments in this thread so we can try and keep things organized. Please submit your feedback by April 30th, 2020. Thanks- Paul TVC Lens Product Description Standard 0.81-DRAFT.pdf
  4. This will be included on the agenda for the next DCS meeting.
  5. We're aware of the missing reference errors and those are being corrected in 3.13 (I hope... it's a Word glitch that seems to keep popping up). I do believe you are correct that the data type is wrong for the tolerance records so we'll work that into the revision as well. Thanks for pointing these errors out.
  6. A web based API would be nice, and there is nothing to say that the transmission method for that API couldn't be converting the XML data to JSON (which works well when XML is the starting data and you have a nice schema). However, the reality is that such a service would be at least a few years away from a published standard and even if we have that tool, many of us who directly support the folks creating these files are going to be dealing with physical files and not web services. You seem to be under the impression that all lens companies use databases to track this stuff. As I've tried to explain during the meetings, that is simply not reality. Have some conversations with Tania or Dave Wedwick, et al, about the type of people they refer to me for help with their lens data. I promise you we will be handling, reading, and troubleshooting lots and lots of text files. Also not every company is going to want to submit their files to centralized DB. We have already proposed this in the past for LDS data, which is much less proprietary, and some larger manufacturers were not interested. So, in the end, we're going to be sharing files via email and such more than pulling things automatically from some web service which hasn't even been defined yet. As for complexity, with a well defined XML schema such complexity is far more easily explained and documented (not to mention the schema will prevent mistakes). The schema itself can be self-documenting. And again, the XML Schema standard is well established while the JSON schema standard has been languishing in draft stage for many years. There are also several tools that can take an XML schema and generate a nice document showing all the links between the elements and attributes that can be directly used in the standard. Essilor has done this with RxML. I'm not aware of any comparable tools for JSON. As for DCS, terseness is the only factor that gives JSON an edge in DCS, as I wrote. I wouldn't object to XML either for the flexibility and, again, the benefits of using XSD. However, if there was a proposal to use JSON for DCS I would not object because it makes sense in that context (real time data exchanges, such as happens in web services) and in reality 95% of the records are simple enough that complex types and other XML types aren't really necessary. JSON was never intended for the type of data we're defining here. Hence the reason the schema definition is taking so long IMO. They are trying to make it as functional as XML when it was never intended to be a replacement for XML. Rather, a supplement to XML specifically for the purpose of web services. After all, the "JS" stands for JavaScript. Again, you can force that square peg into the hole if you want, but it seems like a poor way forward compared to using the correct tool. Most of your counterpoints seem to be "Yes, XML does that but so does JSON". I would argue that in every case other than terseness XML does it better and there are still no factors that make JSON a better choice, only a preferential one, e.g. being more familiar with JSON which to me should not be a factor when writing standards we expect to be adopted internationally. I've worked with both JSON and XML extensively and I would never pick JSON for a project like this because it is simply not the best tool for the job and this is backed up by plenty of information in white papers and tech articles. In any event, as you said, it is apparent we are not going to reach a consensus betwixt ourselves so I'll post the poll with a link to this thread. The poll automatically allows people to post comments so they can state their reasons.
  7. I concur that we will eventually need to put this to a vote. How would you like it to be presented? Simply " Do you prefer XML or JSON?" or with talking points? As for my position, and what I took from the various articles and white papers I've read on the subject, it's really simple. 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. While in both cases one could use the alternative language, doing so is like pounding in a nail with the ball side of a ball peen hammer. You may eventually get the job done but striking the nail cleanly and consistently is more a matter of luck than intention. I'm merely advocating for using the best tool for the job, and to me that is clearly XML. When we start talking about DCS, however, then I'd be more in favor of JSON because terseness is a factor there and we are already dealing with simple data structures and name/value pairs. In any event, let me know how you'd like to present the options and I will create a poll.
  8. That is a very simplistic example. I agree that for short data sets there is value in brevity and this is exactly the type of data where I would go with JSON. The catalogs will not be small data sets. Reading a large mass of data and trying to figure out where the closing tag is in JSON is much more difficult than XML. Additionally, almost all text editors that aren't Notepad can automatically prettify XML and will do syntax highlighting making viewing the data much easier than your black on white example. There are also many more tools already available for dealing with large XML datasets by hand than I've been able to find for JSON. I'm still not convinced, especially by such a contrived example. that JSON is better for this project. Also, the JSON schema standard is still in draft stage. The XML schema standard is well established. I would further argue that as a committee we have more expertise available in XML than in JSON. And what about code generation from XML schema's? That is a huge benefit IMO. We seem to by trying to force JSON to fit, again, because it's newer and sexier, not because it offers any true benefit. JSON is awesome, just not for this. You might find this interesting. It's a fair assessment despite the biased sounding title.
  9. We had a call on this topic yesterday. We will be adjusting the descriptive text to make the intention of the records more clear. This won't be ready for several weeks. 3.13 is being delayed until our next meeting.
  10. My point was that I didn't think anyone would object to changing the nomenclature if we could come up with something better. However, no one had proposed any alternatives. I don't like using "Find" in the abbreviation but it might be a starting point to rethink the descriptors. Your description seems more clear to me. Adopting this change to the narrative will also require completely revising the existing documentation in 3.12. It's a large change and will require rewriting most of that material as well I think. Someone from the committee will need to volunteer to undertake the primary rewrite. I suppose this may require another vote.
  11. Thanks Tony. I was thinking that since a "no" vote at this stage means countering the approval we just did at VEW it would be important to know why people changed their minds. I do appreciate all feedback though. We need more voices on the topic.
  12. 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.
  13. I don't know that the nomenclature is as important as the concept so if you have alternate terms you think would be accurate and less ambiguous, please suggest them.