Validator Alpha report

Plus brief description of

Plus brief description of used validation schema. Like "Janus v0.1, Retrieved ... from http://..."

Thanks Sergiy

Displaying a full list of datasets checked, and a version of the configuration file, are good suggestions. We'll add it to the Alpha2 release.

Report and Processing Message thoughts

What a great idea to have something like this out there. I work with Robert (from Sepracor, who you talked with last week) and have spent some time this week checking the tool out. Here are some of my initial thoughts and issues I ran up against. Related to the above... can the dataset(s) and config also appear on the 2nd GUI display? ("The Validator has finished processing." is currently at the top of the box I am referencing.) If I produce a log file from the CMD prompt window that is more than 3MB, it doesn't open when double-clicked on. I can open it in a text editor and see that the file seems complete and uncorrupted. I thought it might be that I wasn't giving these enough time to open, so left it trying overnight with no luck. Is this a system issue on my side? Any suggestions for getting this to open? Interestingly, if I run the same data area through using the GUI, the report opens fine. I have some concerns over the messages one gets when running through files not accepted by the tool. (i.e. SAS7BDAT files) The report told me "Congratulations! Validation passed successfully." when in fact 0 rows were processed if you look closely at the GUI box. A similar message is given in the CMD window when I tried the same thing there... "The validation has completed successfully. Congratulations." These could mislead a user if they aren't paying attention. In the report itself, when multiple datasets are run, the results seem to be ordered by issue number, then dataset. I believe most users will correct things by dataset, not by issue, so an option to sort the output that way would be nice. Ultimately, as a user, I'd like to see an option for getting output I can manipulate in a spreadsheet. Our current homegrown tool uses the XML tagset from SAS to create an XML file we can open and manipulate in XLS. We think its slick, but we're biased. :-) I think Robert said he was planning to send it over to you to check out. Again, great idea. Fabulous start. Let me know if any of my comments aren't clear. Thanks, Diane

RE: Report and Processing Message thoughts

Thank you very much for your feedback. You've brought up some good points. Let me address the two more technical ones as they are known potential issues. In regard to being able to open the log file produced by the CMD window, we've found that performance is (unfortunately) quite bad for large files in Internet Explorer. Other browsers, such as Mozilla's Firefox and Apple's Safari tend to render the page much faster, and therefore more successfully. I'm not sure which you are currently using, but perhaps another might give better results. The reason that you notice a difference when viewing the log from the graphical client is that the transformations done on the raw XML are done within the client, and your browser displays the resulting HTML file. When viewing a log created from the CMD interface, your browser must first load the large raw XML file and then perform these transformations on its own, which is a more resource-unfriendly process. The reasoning behind this approach is that the CMD interface is (theoretically) more likely to be used as part of an integration scheme, where the implementing program might choose a different way to digest the raw XML log. Conversely, users using the graphical client want to be able to see the logs quickly, so the transformation is done in advance in that case. The issue surrounding the program just gobbling up non-recognized files is definitely a concerning one, and we're hoping to add some robust input-checking features in future releases so this will no longer be a problem. Regards, Tim

Modzilla worked to open the big file

Thanks so much for the tip! Diane