Should canonicalization include 'absolutization'?

[iherman]

At the moment, step 11. of the manifest canonicalization means all relative URI-s are resolved at this step using base. This may be a problem in relation with the value of base in the case of packaged publications, see w3c/pwpub#45.

[iherman]

This issue is the spin off of the telco discussion on 2014-04-29, see Meeting minutes.

See also w3c/pwpub#37

[iherman]

An alternative to the current step 11 would be something like:

Add, to the @context definition array, the object of the form:

{ "@base": "base" }

as the first element of that array.

(Where base is the value of the base URL established earlier in the algorithm.)

@BigBlueHat you mentioned at the call that you saw some other problems with that, can you comment?

[iherman]

Actually... I wonder whether the issue is really with this clause in the canonicalization algorithm. The real question is, really, what the base URL is. While this is not a question for a WPUB served from the Web, it is a question for a packaged WPUB. I.e., the core issue may actually be w3c/pwpub#45.

If w3c/pwpub#45 leads to a conclusion that defines the base URL for a package, the right action may be to document that base URL definition in the packaging spec, and then the canonicalization algorithm can work as defined with that value "plugged in". In other words, this issue may simply be moot.

(There may be a need for an editorial change to accommodate with the conclusions of w3c/pwpub#45.)

Cc @rdeltour

[iherman]

See also w3c/wpub#434...

[llemeurfr]

In the LPF spec, we introduced the term "relative path" (i.e. relative to the root of the package). This term is loosely defined in the LPF spec but is unambiguous used in the zip spec, which states:

4.4.17.1 The name of the file, with optional relative path.
The path stored MUST NOT contain a drive or
device letter, or a leading slash. All slashes
MUST be forward slashes '/' as opposed to
backwards slashes '' for compatibility with Amiga
and UNIX file systems etc.

Step 11 is about URLs explicitly and relative paths are not URLs.
And relative paths don't need a canonicalization step (they are not transformed).

Therefore could we simply add a note on step 11, stating that manifests processed in a package are not affected by this step?

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Should canonicalization include absolutization
Garth Conboy: See Issue 9
Ivan Herman: with the change of having publication manifest and not web publication, absolutization is done in the profile and I wonder if this is something we definitely have to have…
… in the publication manifest now… should it be up to the profiles what happens?
Garth Conboy: It sounds like you’re proposing close with no action?
Ivan Herman: It might be better to wait for Laurent - he had issues with the spec. Let’s put that on the agenda for TPAC when Laurent is around.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Close Issue #9, recent changes to the specification around the canonicalization algorithm mean there is no longer a base.

View the transcript

Wendy Reid: #9
Wendy Reid: this is step 11 of the canonicalization algo
… there’s not a base any more
… that step is gone
… so I think we can close
Laurent Le Meur: I agree with the resolution
… it’s also true for LPF
… which is about something in a zip and says nothing about how it can be exposed on the web where it needs a URL
Proposed resolution: Close Issue #9, recent changes to the specification around the canonicalization algorithm mean there is no longer a base. (Wendy Reid)
Dave Cramer: +9
Garth Conboy: +1
Wendy Reid: +1
Charles LaPierre: +1
Laurent Le Meur: +1
Romain Deltour: +1
Benjamin Young: +1
Brady Duga: +1
Toshiaki Koike: +1
Resolution #4: Close Issue #9, recent changes to the specification around the canonicalization algorithm mean there is no longer a base.