Enhancement: Provide a public PURL Service web form

[DennisClark]

In order to support and encourage universal PURL adoption and improved standards, please consider a new web form, open to the general public, that supports at least 3 things when you enter (or paste) a PURL into an input field:

• Validate the PURL and provide meaningful, helpful feedback if there are problems with it
• Construct a Download URL, when possible, and present that in a copy-enabled, click-enabled field
• Look for the PURL in a public instance of purldb and present that metadata, or a link to a public display of that metadata

Also find ways to publicize the availability of this web form. Also explain how it works and how you can use available tools and API's to do the same thing yourself.

[DennisClark]

For reference, please see https://public.purldb.io/api/validate/

This issue is about providing a user-friendly front end and expanding the results.

[DennisClark]

Another useful feature to provide on the form would be a link to a suitable GitHub project issues page to support questions, suggestions, issues, etc.

[DennisClark]

@johnmhoran when you start working on the UI design, you might get some inspiration from the DejaCode user form to edit a Package, since it breaks out the PURL into its individual parts, so that when your new form provides feedback to the user, it can show how each of the pieces of the user-entered PURL were interpreted. Just an idea!

[johnmhoran]

Thanks @DennisClark -- I'll give that a close look. 👍 Would I be correct in thinking that we're talking about a Django-based front end rather than something related to the forms I've seen connected to a REST API?

[DennisClark]

@johnmhoran not really sue about that, although it would probably make sense to make use of whatever we have done for VCIO.

[johnmhoran]

For example, this UI enables basic querying (both JSON and a more-familiar but more limited HTML form) of the VCIO bulk_search endpoint. I'd guess that this is a REST Framework-specific form with its own abilities and limitations. Django likely provides more options and flexibilities -- and complexities.

I'll start digging into this.

[johnmhoran]

@DennisClark I've created an initial draft of a PURL web form that addresses a subset of the attributes and behaviors you've identified in this issue. When you have time, it would be helpful if we could take a look at the draft UI together and discuss your thoughts on both the current contents and the details of those items above that I've not yet addressed. Here's a sample screenshot:

[DennisClark]

@johnmhoran to summarize a bit our recent conversation, there are 3 cases to consider:

• User enters a valid PURL that happens to exist in the PurlDB.
• User enters a valid PURL (syntactically correct) that does not exist in the PurlDB.
• User enters an invalid PURL (with a syntactical error).

In all 3 cases, we want the user to get some meaningful and helpful feedback, and ideally that means parsing out the specific chunks of the PURL into their specific fields as best as can be determined. If the PURL exists in the PurlDB, we can present some useful selected fields and also provide a link to equivalent API results.

Also, as we discussed, a link from the "About" dropdown should be sufficient to allow the user to navigate to the purldb repo and do further research there, and possibly enter a question issue.

[johnmhoran]

@DennisClark One of your first bullets above refers to constructing download URLs -- Construct a Download URL, when possible, and present that in a copy-enabled, click-enabled field. Do we already have code that does that which you contemplate using as the basis for the construction in the UI? (I'm currently getting the download URL value from the PurlDB record if it exists there.)

[DennisClark]

@johnmhoran there ought to be something in DejaCode that constructs download URLs

[johnmhoran]

@pombredanne The PURL spec prohibits the inclusion of URL Authorities in a PURL, but notes that there can be exceptions, and this example passes both my local code and testing and is validated by the public validate endpoint. Is that because there is something about the specific circumstance that means it is not treated as a URL authority?

pkg:/nefarious/powned/user:password@mydatabase.com:5432

In contrast, this fails (and appears to clearly violate the spec's guidelines):

pkg:hello/user:pass@host:port

ValueError =
        Invalid purl 'pkg:hello/user:pass@host:port' cannot contain a "user:pass@host:port"
        URL Authority component: ''.

[pombredanne]

@johnmhoran an authority would be a combination of user:pass@host:port and would technically come before the namespace/name parts, in all cases I think the colon would likely need to be escaped. In pkg:hello/user:pass@host:port I guess the parsing would either end up failing or would return hello as namespace, user:pass as name, host:port as version.

pkg:/nefarious/powned/user:password@mydatabase.com:5432 would also likely be parsed in something like: nefarious/powned as namespace, user:password as name and mydatabase.com:5432 as version

The point is the spec does not accept nor does not care nor knows about URL Authority (see https://en.wikipedia.org/wiki/URL#Syntax )

In particular a true authority would have to come with // The base URI looks like this:

• URI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]

The base PURL looks like this:

• `PURL = type ":" namespace/name ["@" version] ["?" qualifiers ["#" subpath]

This table shows the components equivalence between each:

URI	PURL
scheme	type
authority	N/A
namespace	path
name	path
version	path
query	qualifiers
fragment	subpath

[johnmhoran]

Thank you for the detailed reply @pombredanne -- greatly appreciated. 🙂

[johnmhoran]

BTW my current draft parses the PURL slightly differently, treating nefarious as the type (a leading/ is disregarded per the spec):