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.

Printing PEDS Data for a Single Application from an XML Download

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.

Linking to Zip or Tar.gz File in Version-Tagged GitHub Release

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.

Improved Browsing of XSLT_PEDS Results

In its generation of Html files displaying data from a large number of search results, XSLT_PEDS 1.0 provides clear utility in overcoming the 20-result viewing limit for data on the USPTO’s PEDS site. Files containing many results can, however, be problematic when attempting to browse for particular results of interest. A new feature added in version 1.1 aims to mitigate this problem.

In files generated by XSLT_PEDS 1.1, you can now click on any application title to hide all of the data sections in the file except the Application Data sections. This allows for rapid browsing through the application data of all of the search results to locate those of interest. Clicking on any title again will show the hidden data sections. Importantly, the browser view of the file remains on the result of which the title was clicked to show the hidden sections, allowing easy review of that result’s sections when a search result of interest is located. The page with sections hidden may also be printed if desired to provide a hard copy containing only the Application Data for each result.

Update (September 21, 2020) : Control of the feature discussed above was changed in XSLT_PEDS 1.2, as discussed in a later post.

The latest version of XSLT_PEDS is available for download here.

Show/hide toggling of sections of an Html document based on a click is technically trivial, of course. Implementation such that large hidden swaths of a document can be shown while positioning the clicked element in a predictable and visible location in all cases is a bit more tricky. My solution was to control the scroll position so as to locate the clicked element at the top of the browser viewing area, which required temporary provision of a trailer at the page bottom to handle an edge case. Those interested in the details are invited to examine the JavaScript, CSS, and HTML in an XSLT_PEDS generated file, or to examine the peds.xsl file in the repository at https://github.com/dfyockey/XSLT_PEDS.


The United States Patent & Trademark Office offers free access to a number of intellectual property data sources. Among these is the Patent Examination Data System, or PEDS, which provides data about and accumulated during the examination of patent applications. A friend recently asked whether I could make some software to convert data downloaded from PEDS into a readable form. Knowing nothing about PEDS, I followed the link he provided and took a look.

PEDS is searchable through a web interface at https://ped.uspto.gov/peds and provides all of the aforementioned data for each search result. Unfortunately, only a preview of the resulting data including the first twenty results is viewable through the site. It’s necessary to download the data in JSON or XML format to access the remaining results.

43 Results, but you can only look at 20… Bummer.

No tools are provided for handling the downloaded data, so it’s left to the user to obtain or devise software to parse and format the data into a readable form. Failing that, one on a budget must resort to reading the unparsed data in a browser or editor, as I was unable to find any free or inexpensive tools for the purpose.

After some consideration and random poking around, I discovered Extensible Stylesheets Language for Transformations, or XSLT, and realized that an XSLT stylesheet might be used to do the job. For those not familiar with XSLT, an XSLT stylesheet can be used to transform an XML document into a different form, such as a neatly formatted HTML or XHTML document that can be viewed in an ordinary web broswer.

A good amount of nose-to-the-grindstoning culminated in a workable XSLT stylesheet, along with some scripts to make for easy generation of HTML files from XML data downloaded from PEDS. In contrast to the PEDS site preview, the resulting HTML files include the data for all of the search results. The data may be provided in a single file or by year in a plurality of files, depending on the user’s choice, and each file can be scrolled through to view the data without need to click drop-down links or tabs as required on the PEDS site.

The combination of stylesheet and scripts is called XSLT_PEDS. The latest version is available for download here. Requirements, setup, and usage information may be read online at https://github.com/dfyockey/XSLT_PEDS.

Below is an example comparing a portion of data as presented on the PEDS site, and a resulting HTML page generated using XSLT_PEDS. The PEDS site view on the left was pieced together from a plurality of screenshots, as it’s not possible to view data on the site in a scrollable or printable format. The XSLT_PEDS result view is a screenshot from a single, scrollable and printable webpage. If one downloads data for 100 results and choses to translate it into a single file, the data for each result is provided in the format shown separated by dashed lines, and one can easily scroll through all 100 to view the data.

PEDS Data from USPTO’s sitePEDS Data generated by XSLT_PEDS

Hopefully XSLT_PEDS will be of use to those wishing to more readily access the free data provided by the USPTO through the PEDS site. If you’re using it and happen to notice anything erroneous or missing between the data in the generated HTML pages and the data on the PEDS site, please let me know in a comment here or by filing an issue at https://github.com/dfyockey/XSLT_PEDS/issues.

The Hubbish Flow?

My need has been for a workflow adequate for a sole developer and that takes as little work as possible to follow. That last bit is lo más importante for me; if I find it tedious and lack a requirement from being in a team, I’ll let it fall by the wayside and be back where I started.

After considering various pros and cons of a number of existing workflows, I came up with a tweaked version of the GitHub Flow that it seems would work the best for my purposes. Call it the “GitHubbish Flow” or just the “Hubbish Flow.” Professional developers might think it an undesirable approach, but it’s described below on the off chance that someone else might find it useful.

Assuming use by a sole developer, the Hubbish Flow goes like this:

  1. The main branch is a development branch to which only merges from feature branches are made.
  2. To work on something new, create a feature branch with a descriptive name (e.g. new-oauth2-scopes) branching off from main.
  3. Clone the feature branch separately to your local machine (git clone --single-branch --branch <branchname> <remote-repo-URL> <remote-repo-name.branchname>).
  4. Commit to the feature branch locally, and regularly push your work to the same named branch on the server (git push origin <branchname>).
  5. When the feature branch is ready for merging, open a pull request.
  6. Merge the pull request into main (i.e. don’t use “squash and merge” or “rebase and merge”), and delete the merged feature branch.
  7. When the main branch reaches a desired release point, tag the release point to create a release.

A “feature” may be an actual feature, a bug fix, or any other conceptual aspect of a project. And, of course, multiple feature branches may exist simultaneously to facilitate parallel feature development if desired.

Using the main branch for ongoing development rather than immediate release, and instead tagging particular points as releases facilitates relationship of feature groups with releases. That is, you can say things like, “Version X has new features A, B, C, D, and E.”

Separately cloning feature branches prevents following through on any impulse to commit something directly to the main branch.

The use of pull requests and merging performs merges using the no-ff option, creating a merge commit along with the code commits for each merge. While some consider such commits to be redundant clutter, they provide direct access to their associated code commits, even if the code commits in the full history are interleaved in time with those from other merges. When viewing the repository, the merge commits may then be listed separate from the full commit history by clicking Pull requests, or by searching Merge Pull Request and clicking Commits on the search results page. The search results page provides more information in the resulting list than the Pull requests page and conveniently groups merges from same-named branches together in the list; it can be useful to save a bookmark to the search results page to easily access the list when needed.

Finally, deleting feature branches after merging just avoids clutter, and isn’t worrisome since a branch can always be restored if needed.

In Need of a Workflow

As an individual developer, I’ve been using GitHub — to quote a Software Engineering post — “very simplistically: no branches and basically just using the commits as a backup to my local files.” Following that path, the plan today was to commit completed Chess Opponent throttling control code with a hardcoded throttle value, to replace the hardcoded value with one or more options to set the throttle value, and then to commit that as well. The separate commits were to make rolling back to the working hardcoded version if I mucked things up with the options.

I realized, though, that it’s probably not best to continue that way, committing features to the main line of the code in a piecemeal manner with other little tweaks and bug fixes sprinkled through to confuse things further, and I finally got fed up with having everything in such a disordered state. So instead, of committing anything right now, I’ve decided to take a few days and try to establish a reasonable workflow to make things clearer and more organized from this point on.

While poking around for info on GitHub-applicable workflows, I’ve collected a few items to mull over that might be of interest to others:

The plan now is to get a workflow established in short order and get on with development in a more organized manner going forward. Should be easy, right?

Chess Opponent

There’s something about playing chess on a physical board that makes for a better game. With that in mind, I poked around a bit trying to find a chess program for use in playing on a physical board that, at a minimum, communicated it’s moves using chess notation and had no distracting onscreen board. They probably exist, but I didn’t run across one in short order. So I turned my attention to the possibility of modifying GNU Chess to serve the purpose.

Aside from being used as an engine with applications like Xboard that provide a GUI onscreen board, I knew that GNU Chess could be run alone in a terminal where its output is text-only. In that case, the program conveniently displays the computer’s moves in standard algebraic notation (SAN) and accepts user moves as input of either SAN or coordinate notation. It also has the drawback of automatically displaying a text representation of the current board after each move while providing no means to disable that display. It seemed it would be simple to provide GNU Chess with such a means.

It turned out to be more complicated than expected. The convoluted (at least to me) nature of the program’s code, an apparent consequence of many changes by multiple people dating back to the 1990s, frustrated determination of where to make changes and what changes needed to be made.

While wading through the code, other improvements came to mind, and I finally decided to fork GNU Chess rather than just doing a patch or two. The fork needed a name, so I went with what it was intended to be: a “Chess Opponent.”

What’s been accomplished so far:

  • Eliminated default automatic board display.
  • Added in-game commands to display the board from either black or white perspective to facilitate checking for suspected human errors in physical board piece positioning. Because we’re all bound to make some.
  • Created a logo for use as an icon or whatever (shown above).
  • Added user selection query of side (i.e. black or white) before each new game.

What’s currently in the works:

  • Selective throttling control CPU core usage while “thinking” during the user’s turn to thereby enable reducing power consumption. As with GNU Chess, usage of a CPU core for such activity is currently either 100% or 0%.

Functionality on the drawing board:

  • Command, help, and usability improvements.
  • Modifications to the selection query at the start of each new game, including:
    • addition of a random option.
    • addition of default selections, including:
      • random for first new game since program start.
      • the color opposite that just played for second and subsequent games.
  • Option to display move output in coordinate rather than standard algebraic notation.
    • An in-game command for switching between notations.
  • Optional voice output to enhance play and facilitate use by people with visual impairments.
    • Functionality for easily navigating and reading out particular positions on the board to facilitate error correction by people with visual impairments. Being human, they’re bound to err, too.
  • Optional move output using cowsay, just for fun.

If you’d like to try it out or fork it yourself, the source code and latest release of Chess Opponent are available in my chessopp repository on GitHub.

Hello, world!

Starting a blog without some introduction seems too abrupt, sooooo… Here’s a bit of introduction:

This blog’s intended purpose is to pass on info to anyone interested about free open source software that I’m currently working on, how that’s going, what progress is being made, and the like.

Wow. That’s a pretty minimal introduction, isn’t it? Oh well. On with the blog!