Re: Review Prov-AQ

Hi Sam,

Many thanks for your review and comments.  I've applied most of the changes, 
just a couple passed over for now.  More detailed responses are below.

An updated editors' draft is at 
https://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html

On 05/04/2013 09:34, Sam Coppens Ugent wrote:
> Hello,
>
> Here is my review of
> https://dvcs.w3.org/hg/prov/raw-file/fa9bac23203a/paq/prov-aq.html
> It looks fine to me. I have no blocking issues.
>
>
> 1) Third Public Working Draft
>
> This is the third public working.   --> This sentence needs to be updated.
Indeed it does.  I've removed that for now, with a view to it being updated when 
the document is staged for publication.
> 2) 1.1 Concepts
> This document uses the term URI for ... --> I would consider moving this
> paragraph above the concept definitions (Resource, etc.
OK. Done.
>
> 3) 1.2 Provenance and Resource - Second paragraph
> Yet we may still want ... --> Yet, we may still want ...
OK. Done.
> 4) 3.1 Resource accessed by HTTP
> may be indicated using an HTTP Link: header field --> may be indicated using
> an HTTP Link header field
OK, I've changed all such (in-text) occurrences through the document, except one 
case where it is used alongside with HTML <Link> where it may help to highlight 
the distinction.
>
> 5) 3.1 Resource accessed by HTTP
> Example 1 and example 2: I would consider using different URIs for the
> provenance records (http://example.com/resource/provenance/), because often
> both the normal HTTP access (#has_provenance) and a query service
> (#has_query_service) will provided next to each other. One access protocol
> will not replace the other. Makes it more clear.
>
Good catch!  Yes, I agree.  Done.

> 6) 3.1.1 Specifying Provenance Query Services
> There may be multiple has_query_service link header fields... --> There MAY be
> multiple ...
>
Done.
> 7) 3.3 Resource represented as RDF
> First paragraph: For this purpose the link relations introduced ... --> For
> this purpose, the link ...
>
OK, done.
> 8) 4.1 NOTE on service descriptions offered by LDP
> They won't develop generic service descriptions, maybe specific service
> descriptions for their read/write interface, but nothing more.
>
Ah, OK - that was based on a not-very-strong impression I had from my exchanges 
with Erik Wilde.

I should probably drop this note, as it doesn't really add anything to the spec. 
  (I've just commented it out in the ReSpec source, so it could be reinstated 
again if anyone things it should be.)

> 9) 4.1.1 Direct HTTP query service description
>  (level 2 or above) in which which the variable uri stands for the target-URI
> --> ... in which ...
>
Done.
> 10) 4.1.1 Direct HTTP query service description
> Example 6: Consider using an entity uri containing # or & ...
>
That example has now been moved to the invocation section, and the discussion of 
pre-escaping '#' and '&' has been dropped. I'm not sure that a specific example 
for this case would now add anything.

> 11) 5 Provenance Pingback
> I consider this section essential for more advanced provenance
> platforms/tools, e.g., discovery of the latest published version, even if in
> another domain. Thus, I am certainly in favor of keeping this section.
>
Ack.
> 12) 5 Provenance Pingback
> Consider using in the example using an anchor parameter to make things more
> clear.
>
The examples inthis section have been reorganized.  Which example were you 
thinking of?  (Example 11 in the current revision *could* include anchors, but 
I'm not sure I want to include them there if they're not overriding the default 
(normal) case.  But I'm open to adding them there if you think it makes the 
intent clearer.)

> 13) 6 Security
> CSRF can be a real thread: a user ,e.g. , follows a provenance link, but it
> links to a script that tries to do a bank transaction (under the consideration
> the user is logged in to its bank account)
>
Thanks!  (Stian pointed this out too.  I've added some additional text to try 
and expose this.)

#g
--

Received on Monday, 8 April 2013 09:37:46 UTC