Re: some rq23 grammar comments

Dave Beckett wrote:
> Looking at Appendix A of CVS 1.477
> First para - wasn't there some additional words about notation including
> the following sections going to go here?

Yes - just haven't finished editing yet - that was a discussed in email 
yesterday 30mins before the telecon.

(Had a CVS problem this AM and I lost time over that)

> IRI References
> Need to mention the base URI used to resolve things and where it comes
> from.

Earlier, Eric has put: (2.1)

SPARQL provides an abbreviation mechanism for IRIs. Prefixes can be defined and 
a QName-like syntax [NAMESPACE] provides shorter forms. Prefixes may be used 
anywhere after they are declared; redefining a prefix causes the new definition 
to be used from that point in the query syntax. The base IRI for the resolution 
of relative IRIs may be explicitly declared with the BASE keyword.

I added the text after "," in:

They are converted to absolute IRIs according to RFC 3987 and RFC 3986, using 
the base IRI defined by the BASE clause if present in the query.

> White space
> ... terminals ...
> Note that I do use different terminals and am very unlikely to change
> them for reasons of implementation, error-recovery and the split I have
> now works well.
> "white space in terminals is significant"
> The choice of terminals is implementation specific.  Whitespace is
> significant only in a few terms which maybe could be listed - the IRI
> (IRIref), names (NCNAME, VARNAME, NCNAME_PREFIX) and string literal
> terms (RDFLiteral or String).  Some of them only via \u0020

Only string literals.  Text in the \u section says you can't sneak \u0020 into 

We do need to say that whitespace separates terminals e.g.

?x ns:p

needs some separation else it becomes ?xns :p

Replaced "White space in terminals is significant." with "White space is 
significant in strings, otherwise white space is ignored."

White space is used to separate two terminals which would otherwise be 
(mis-)recognized as one terminal.  White space is significant in strings, 
otherwise white space is ignored. As a hint, rule names below in capitals 
indicate a possible choice of terminals.

> Keywords
> "Keywords are shown in upper case but are matched in a case-insensitive
> manner."
> except there are a few mixed listed: isURI isBLANK isLITERAL

"Keywords are matched in a case-insensitive manner."

I prefer to keep the casing to make the more readable.

> Dave


Next message ...

Received on Wednesday, 31 August 2005 14:16:31 UTC