Yesterday, I finished up and released version 2.0 of XSLT_PEDS, the latest version of software to facilitate reading USPTO’s PEDS data. Script code in the new version has been significantly reworked to improve ease of maintenance while providing controls to facilitate incorporation of XSLT_PEDS functionality into other scripts if desired. Fortunately for current XSLT_PEDS users, those upgrading to version 2.0 may continue using scripts `unzipa`, `unzipf`, and `unzipo` as with versions 1.x.x.
Version 2.0 includes the new script `unzippeds` which includes all of the functionality formerly found in scripts `unzipa`, `unzipf`, and `unzipo`. When provided with the appropriate argument, `unzippeds` will perform the operation of the corresponding one of the former disparate scripts. The former scripts remain but have been reduced to stubs calling `unzippeds` with appropriate arguments. Integration into a single script obviously reduces redundancy due to similarities between operations, but the single script and its arguments also simplify selective application of any or all of the XSLT_PEDS functionality into other software. Use in other software is permissible, of course, in accordance with GNU GPL-3.0.
In addition to code changes, XSLT_PEDS 2.0 has been newly tested on Microsoft Windows 10 using Cygwin in addition to testing on Linux and on Windows 10 using Windows Subsystem for Linux (WSL). Guidance on requirements and usage with each is included in the release’s README file, which is also available for reading online at https://github.com/dfyockey/XSLT_PEDS.
The latest version of XSLT_PEDS is available for download at https://github.com/dfyockey/XSLT_PEDS/releases/latest/download/XSLT_PEDS-release.zip.
The only way to print data for a single application from an Html file generated by XSLT_PEDS 1.1 and earlier was to either print the pages including the data, which would also include data for other applications that happened to fall on the first or last printed page, or to copy & paste the data into a word processor and print from there. XSLT_PEDS 1.2 added the ability to easily print data for a single application directly from the generated Html file.
To implement this new feature in an intuitive way, it was necessary to change the hide/show feature added in version 1.1 and discussed in an earlier post. In version 1.2 and later, clicking on any Application Data heading, rather that clicking on any application title, will hide/show data other than in Application Data sections. This freed up a click on an application title to be applied to the new feature.
Now to print the data for a single application, first click the application’s title. Clicking on an application title will hide/show all data for all applications except for the clicked title’s application. With other data hidden, the browser’s print function will print only the remaining data for the one application.
The latest version of XSLT_PEDS is available for download here.
In the two preceding posts of this blog, I wanted to provide a direct link for a reader to download the latest version of the software discussed, regardless of how many changes had been made to the software since the posts were published. I also wanted to have my releases in GitHub tagged with the version number for the release.
The best GitHub seems to offer in this situation is a link to the page for the latest release from which one has to download the correct file, as discussed on the GitHub Docs page Linking to releases. Given that this is a version-tagged release, directly downloading a particular file requires a link to include the version number of the release. Such a link would no longer point to a file in the latest release after a new release was created, but rather to a nonexistent file in the new release.
Lrfg, for Latest Release Files Generator, is a proof-of-concept bash script I put together for working around this problem (and for editing the releases a bit in the process). Lrfg uses GitHub’s REST API to download information about the latest release, download the zip file from the release, create two files named <repo>-release.zip and <repo>-release.tar.gz from it, and upload them as new assets to the latest release.
In use over multiple releases, each release will have like-named zip and tar.gz files. Consequently, the latest release zip file, for example, may be accessed without reference to the version number using the address
github.com/<user>/<repo>/releases/latest/download/<repo>-release.zip. By running lrfg against each new release, a <repo>-release.zip file would be provided for each release, and that URL would always point to the latest of those files. The tar.gz file can be accessed via a similar URL if desired.
As currently implemented, Lrfg modifies the zip file contents as desired before creating the new files, although this isn’t necessary to provide the linking discussed above.
Lrfg is available for cloning, forking, and download at https://github.com/dfyockey/Lrfg.