LD Patch initial comments

>From July 14 minutes >  Draft added to Mercurial 
http://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html 

I note this is on its own branch.  What's the utility of that?  It's not 
like the sensible case we had with bblfish where he was making 
"prospective updates" to existing documents that others were hacking away 
at in parallel.  This is one file, in most cases the editors are going to 
fuss with it and no one else.  I was going to fix some clear typos myself, 
but creating a new repo locally to keep the branches untangled is more 
effort than it's worth to me.

Non-typo comments:

1: This seems "bigger than a breadbox".  I'm honestly not sure it fits in 
5 months, given its current state.  Unless Sandro et al. warrants that 
nearly all of the Frankensyntax is re-used, and with all the dependencies 
it needs easily added, this feels like another iteration of "oh for pete's 
sake how hard could this possibly be?" playing out.

2: Printing on std US paper at a reasonable font size, many of the 
examples overflow the right margin at least once.  Anything with a path is 
likely to overflow, for starters.

3: My sensible side assumes that whitespace between lexical tokens is (a) 
allowed and (b) follows the common definitions, but I can't actually 
verify that from the BNF body parts in here (I seem to be on a Halloween 
theme today), so there may be unstated "global" assumptions that need to 
be added ... and if so, one hopes that they are compatible with all the 
graves whence the parts were collected.

4: The text media type tree seems like an odd choice.  I expected 
application/

5: The unicity constraint definition leaves me hanging on the "...or 
what?"  I.e. what if the path is NOT unique up to the point where the ! 
occurs?  I'd guess you're implying that's an error, but I find nothing in 
the text really to support my supposition ... it's just the least 
surprising choice (to me).

6: 2.4 talks about the variable "pointing" at an RDF Term (sic).  Keeping 
with the binding theme instead of switching to "point*" might be clearer. 
E.g. "...will be bound" or just "...is bound".

7: 2.6 suggests (by omission) that it is impossible to delete a list, 
although (in later sections) it's possible to empty a list.  The asymmetry 
of being able to add a list, but not delete it again later, seems vaguely 
suspect although I have no concrete use cases requiring it.  At some level 
I think about it as: can I undo whatever havoc I cause?  ...and the answer 
here appears to be 'no'.

8:  The (first) Path BNF is ( step | constraint ) *  ... so I can have two 
consecutive constraints.  The end of 2.4 is all I see wrt those 
constraints, so if I put >1 on here, how do I know their relation? 
Guessing again, you want And... as in, meets all constraints.

9:  I don't see any Abstract Syntax definition for UNICITY_CONSTRAINT. 

10: I'm not sure how to reliably interpret section 4, even after following 
my nose to the first 2 links.  I get the sense that you're asking me to 
somehow apply BNF syntax to the content of those pages, which don't appear 
to have any remotely similar syntax. 

11:  Given that Constraint wanders into comparison for equality, you need 
rules for that if anyone is going to reliably interop on it.  In paging, 
we re-used SPARQL's rules.  Otherwise you have to lay out the various 
cases like typed ?= untyped if the lexical value is otherwise identical, 
which history shows are not trivial to get complete and right.


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead