Allow a URI to designate a library as of a "part of" declaration.

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 4e37d5dc799d6982466ca5651ff04395e839e2b6..d9c3df16d6a78428a308b91ae7d3e33be02cdad1 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -6900,22 +6900,32 @@ A {\em part directive} specifies a URI where a Dart compilation unit that should
 
 \begin{grammar}
 {\bf partDirective:}
-   metadata \PART{}   uri `{\escapegrammar ;}'
+   metadata \PART{} uri `{\escapegrammar ;}'
     .
 
 {\bf partHeader:}
-      metadata \PART{} \OF{} identifier (`{\escapegrammar .}' identifier)* `{\escapegrammar ;}'
+      metadata \PART{} \OF{} libraryDesignator `{\escapegrammar ;}'
     .
+
+{\bf libraryDesignator:}
+      identifier (`{\escapegrammar .}' identifier)*;
+      uri
+    .
+
 {\bf partDeclaration:}
       partHeader topLevelDefinition* EOF
     .
 \end{grammar}
 
 \LMHash{}
-A {\em part header} begins with  \PART{} \OF{}  followed by the name of the library the part belongs to.  A part declaration consists of a part header followed by a sequence of top-level declarations.
+A {\em part header} begins with \code{\PART{} \OF{}} followed by the name or URI of the library the part belongs to.
+A part declaration consists of a part header followed by a sequence of top-level declarations.
 
 \LMHash{}
-Compiling a part directive of the form \code{\PART{} $s$;} causes the Dart system to attempt to compile the contents of the URI that is the value of $s$. The top-level declarations at that URI are then compiled by the Dart compiler in the scope of the current library. It is a compile-time error if the contents of the URI are not a valid part declaration. It is a static warning if the referenced part declaration $p$ names a library other than the current library as the library to which $p$ belongs.
+Compiling a part directive of the form \code{\PART{} $s$;} causes the Dart system to attempt to compile the contents of the URI that is the value of $s$.
+The top-level declarations at that URI are then compiled by the Dart compiler in the scope of the current library.
+It is a compile-time error if the contents of the URI are not a valid part declaration.
+It is a static warning if the referenced part declaration $p$ has a library name or URI different from the name or URI of the current library.
 
 \LMHash{}
 It's a compile-time error if the same library contains two part directives with the same URI.
@@ -6987,7 +6997,7 @@ The intent is that, during development, Dart programmers can rely on a package m
 }
 
 \LMHash{}
-Otherwise, any relative URI is interpreted as relative to the location of the current library. All further interpretation of URIs is implementation dependent.
+Otherwise, any relative URI reference is interpreted as relative to the location of the current library. All further interpretation of URIs is implementation dependent.

[eernst, 2016/11/11 10:37:42]

I cannot find any other occurrences of `URI reference` in the spec. Why is the
addition of `reference` needed here?

[Lasse Reichstein Nielsen, 2016/11/18 09:50:24]

Because a URI cannot be relative, but a URI reference can. It's all part of the
nitty gritty details of RFC-3986, but a relative path is not a "URI". You
resolve a URI reference relative to a URI to produce a new URI.

Our Uri class confuses this by covering both URI and URI reference - because
most users don't know the difference and can't be bothered to distinguish - but
the spec shouldn't be excused for not knowing what the words it uses actually
means.

[eernst, 2016/11/18 13:12:06]

Wow! - acknowledged.

 
 \commentary{This means it is dependent on the embedder.}