Spec: specify what URIs in imports resolve against

[DartBot]

This issue was originally filed by marti...@probst.io

---

The specification (0.08) in sections Imports and Includes refers to URIs, e.g. "An import provides a URI where the declaration of the imported library is to be found."

It does not specify what a relative URI would resolve against, options would be the URI of the "main" dart file that's imported first, the URI of the HTML file that embeds the Dart application, or the current source file (which appears to be what's implemented at the moment).

It also does not specify which URI spec should be applied, RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt), RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt), or even RFC 1630 (http://www.ietf.org/rfc/rfc1630.txt, really old and obsolete).

[anders-sandholm]

Added Area-Language, Triaged labels.

[gbracha]

Set owner to @gbracha.
Added Accepted label.

[anders-sandholm]

Added this to the M1 milestone.

[gbracha]

I imagine we want the latest IETF RFC on this, but in fact, I am reluctant to specify anything about URI interpretation, as this wil depend on the embedder. This includes what to do with relative URIs (package managers may choose one policy, non-file based environments another etc.) how to treat special URI schemes (like dart: or package:) and even standard URIs (which might depend on the browser.

[DartBot]

This comment was originally written by marti...@probst.io

---

URIs are hard, I think no browser actually implements a proper RFC compliant environment. So admittedly specifying something there might be more trouble than it's worth.

However I'd have hoped that Dart would specify what relative URIs are supposed to mean. The import structure of a collection of Dart sources seems to be an important piece of the language.

It seems a bit conflicting to specify that it's URIs on the one hand, but then have the embedder do something magic afterwards without using or mandating anything that happens with the URIs. From that perspective, you could also just drop the URI part entirely and just treat the imports as opaque strings, right?

[gbracha]

Martin,

I agree this is a grey area. I personally think imports should use identifiers and let the environment sort things out. As for relative URIs I can imagine environments where you want different things. I hope we'll resolve this soon.

[peter-ahe-google]

Incidentally, I outlined something similar in issue #3148.

The URI in an #import or #source tag should be resolved as described in RFC 3986. When resolving a URI, one must determine the base URI. For #import and #source tags the base URI should be the retrieval URI of the compilation unit in which the tag appears. See http://tools.ietf.org/html/rfc3986#section-5.1.3

I don't see how the resolution mechanism would interfere with any embedder, in fact, I see it as a problem if a naive embedder makes distinctions between relative URIs and absolute URIs. So I think this should be described in the specification.

And just to make sure this has been said: a relative URI is not a file name.

[gbracha]

The 0.11 draft now contains a description of package:, dart: and relative URI behavior, all ultimately dependent on the embedder's interpreation of URIs. I think this is all we can do.

---

Added Done label.