--- a/model/comments/issue-438-graham.txt	Mon Jul 09 11:03:37 2012 +0100
+++ b/model/comments/issue-438-graham.txt	Mon Jul 09 11:13:36 2012 +0100
@@ -58,7 +58,8 @@
    > separate document isn't really a useful separation - see comment at
    > top).
 
-Noted.
+Whether we have prov-n as an appendix or not, wouldn't change the fact
+that we have those tables with cross reference to dm definitions.
 
    > 
    > I'd also suggest using production names that are a bit more evocative;  e.g., in section 3.1.2:
@@ -73,7 +74,9 @@
    > 
    > etc.
 
-
+Do you mean just for this production?
+Or for all productions?
+In the latter case, this would substantially increase the number of productions.
 
    > 
    > 
@@ -87,15 +90,25 @@
    > blocker, but I find the all-or-nothing approach to optionals is a bit
    > unexpected.
    > 
+
+all-or-nothing is what was agreed by the WG.
+It used to be that we could drop the trailing identifiers, but this was
+deemed ambiguous.
+
+
    > Section 3.7.2
    > 
    > This section introduces reserved attribute names, but there's no
    > indication of where to look for a description of what they mean.
+
+Stian made the comment also:  add ref to DM.
    > 
    > SECTION 3.7.3.1
    > 
    > This section introduces reserved type values, but there's no
    > indication of where to look for a description of what they mean.
+
+Stian made the comment also:  add ref to DM.
    > 
    > Section 3.7.4:
    > 
@@ -107,6 +120,9 @@
    > 
    > I would not repeat the namespace URIs here.
    > 
+
+TODO
+
    > Section 4
    > 
    > I think someone else has commented on the presentation of "toplevel
@@ -125,6 +141,13 @@
    > 
    > A PROV-N expression matches the _bundle_ syntax production.
    > ]]
+
+This is the purpose of section 2.2.
+
+In fact, we may want to break section 2.2 in two subsections, just
+after the definition of production.
+
+
    > 
    > 
    > Section 5:
@@ -132,6 +155,9 @@
    > For this, especially as it's an IETF standards-tree registration, I
    > would expect the change controller to be W3C, and possibly also the
    > contact.
+
+See EDitor's draft, this was already updated.
+
    > 
    > @sandro: does the W3C maintain email addresses as contact points for
    > IETF registrations (URI schemes, MIME types, header fields, etc.)?
@@ -154,12 +180,23 @@
    > 
    > The second paragraph doesn't make sense to me: PROV-N does NOT express
    > arbitrary application data.
+
+See EDitor's draft, this was already updated.
+
+PROV-N is used to express the provenance of arbitrary application data; 
+
    > 
    > This section ignores (or obscures) the (IMO) fundamental issue that
    > provenance is intended to be used to make trust decisions, and as such
    > the reliability of provenance information used must be carefully
    > considered according to the importance of the decision.
    > 
+
+See EDitor's draft, this was already updated.
+
+PROV-N is a language for describing the provenance of things, and therefore a PROV-N document is metadata for other resources. Untrusted PROV-N documents may mislead its consumers by indicating that a third-party resource has a reputable lineage, when it has not. Provenance of PROV-N document should be sought."
+
+
    > ...
    > 
    > End of review comments