Define a PURL as structure

[ppkarwasz]

Currently the PURL is defined as either an RFC 3986 URL or a WHATWG URL:

A purl is a valid URL and URI that conforms to the URL definitions or specifications at:

• https://tools.ietf.org/html/rfc3986
• https://en.wikipedia.org/wiki/URL#Syntax
• https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax
• https://url.spec.whatwg.org/

There is however a big difference between the two:

• RFC 3986 defines a URI as an ASCII string and its components are given by syntactic rules.
• WHATWG defines a URL as a struct of Unicode strings and leaves the serializing/parsing details to other sections:

  A URL is a struct that represents a universal identifier. To disambiguate from a valid URL string it can also be referred to as a URL record.

Should we define a PURL in the same way as WHATWG? This would remove a lot of serialization/deserialization details from the definitions:

• scheme:

  • The scheme is a constant with the value "pkg".

• type:

  • The package type MUST be composed only of lowercase ASCII letters and numbers,
    '.', '+' and '-' (period, plus, and dash).
  • The type MUST start with an ASCII letter.

• namespace:

  • The namespace is a possibly empty list of segments.

• name:

  • The name is a Unicode string.

• version:

  • The version is a Unicode string.

• qualifiers:

  • The qualifiers are a map with Unicode strings as keys and values.
  • The key must be composed only of ASCII lowercase letters and numbers, '.', '-' and
    '_' (period, dash and underscore)
  • The value is any Unicode string.

• subpath:

  • The subpath is a possibly empty list of segments

• segment:

  • A segment is a Unicode string.
  • A segment MUST NOT be empty, . or ..
  • A segment MUST NOT contain a solid / character.

The rest of the details (percent-encoding, transforming to lowercase, dropping empty segments, etc.) can be kept in the parsing/serializing sections.

[jkowalleck]

Should we define a PURL in the same way as WHATWG? This would remove a lot of serialization/deserialization details from the definitions

👍 for simplifying this encoding hassle.

But i think this would NOT remove the serialization/deserialization details from the definitions. i mean, PURL is not the usual url format, or is it?
we don't have scheme:user:password@host/path?querystring#fragment
but instead scheme:type/namespaces/name@version?qualifiers#subpath

PS: I might have understood you wrong. You don't want the PURL to be a WHATWG URL, but you meant o use the same approach that WHATWG uses - they don't specify encoding, but accept any Unicode and leave it to others to encode bytes in Unicode?

[jkowalleck]

@johnmhoran @pombredanne @matt-phylum

[matt-phylum]

I think the request is that the documentation for the different components describes only the unescaped, deserialized forms of the components, with the encoding details handled in the "how to build" section: instead of saying something like "a qualifier value one or more of [ASCII character that doesn't need to be encoded] or [encoded character]" (eg path), saying "a qualifier value is a non-empty string" (eg URL representation).

I remember in a recent PR for PURL I was complaining about some language that said a parser MUST return an error if a PURL component that can represent any Unicode character contained any illegal characters. The author likely intended to mean that the serialized form must not contain any ambiguous characters, but that could also be interpreted that implementations need to validate the encoded string and error if it contains any characters that are not ambiguous but are normally escaped (eg spaces), which is an unnecessary complication, especially for implementations that are based on an existing URI/URL implementation and may not have access to the encoded form. There are three concerns: what characters are allowed in the input (spaces MAY be encoded), what characters are allowed in the component (only spaces are spaces), and what characters are allowed in the output (spaces MUST be encoded). Separating the definition of the component from its parsing and formatting rules could help, especially for complex components like subpath.

[ppkarwasz]

I think the request is that the documentation for the different components describes only the unescaped, deserialized forms of the components, with the encoding details handled in the "how to build" section: instead of saying something like "a qualifier value one or more of [ASCII character that doesn't need to be encoded] or [encoded character]" (eg path), saying "a qualifier value is a non-empty string" (eg URL representation).

Yes, it would be nice for the documentation to describe the components after splitting, decoding and canonicalization. So a path would be a list of string (e.g. foo, bar/baz, ., .., empty) and some path segments would be declared as invalid (., .., bar/baz, empty).