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.

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.