URL comparisons when retrieving metadata files

[danbri]

When comparing URLs for this purpose, what do we say if anything about non-string-identical URIs eg. http://example.COM/ vs http://example.COM:80/, rel=canonical etc?

See http://www.w3.org/2015/05/20-csvw-irc#T14-27-34

[gkellogg]

This is based on Table Compatibility:

Two table descriptions are compatible if they have equivalent normalized url properties.

url is a link property, so the following is used:

If the property is a link property the value is turned into an absolute URL using the base URL.

So, they're not canonicalized, but are made absolute by joining to the base URL.

I think the text is clear, can we close this?

[danbri]

The question is rather whether a modern W3C spec ought to be comparing URIs/(IRIs?) as strings, vs some other deeper check for equivalence. I'm not thinking of semweb "sameAs" for refers to the same real world thing, but rather equivalencies baked into the URI family of specs, e.g. meaning of :80, case insensitivity of domain names, perhaps some internationalization concerns.

[gkellogg]

Probably the best route is to simply reference [[RFC3968]] section 6 "Normalization and Comparison". There is an unbounded set of potential scheme normalization rules, but we might want to limit ourselves to just HTTP and HTTPS normatively.

This would affect Table Compatibility as well as Metadata Discovery (where it determines that the metadata refers to the URL used for discovery.

I've marked it for discussion on the next call.

[gkellogg]

Note that commit 62ff8ec addresses this, not a PR until the issue has been discussed and resolved. In addition to my comments above, it involves link property normalization to be consistent. (didn't consider @id normalization).

[JeniT]

I will raise this with TAG when I speak with them.

[JeniT]

TAG has no objection to using [[RFC3968]] section 6 "Normalization and Comparison", so please go ahead with that PR.