Re: Syntax modifications

I had no problems implementing [1] this new grammar.
I prefer this grammar. More on this later. I just wanted
to give folks a chance to play with it if they wanted.

On Mon, Aug 09, 2004 at 04:31:31PM +0100, Seaborne, Andy wrote:
> 
> 
> We do not have to pin it down yet but concrete syntax matters in expressing
> testcases.  It is helpful to have a syntax that can express the range of
> testcases and then evolves as the draft evolves.
> 
> In the initial strawman, there was no graph nesting : graph patterns resided
> in clause level only so there was only a restricted form of pattern
> combination.  The requirements on the language (particularly
> 3.13/Disjunction but also 3.6/Optional Match ifnested optionals are allowed)
> suggests two or more graph patterns can be combined. Enforcing only top
> level disjunction is a burden on the application writer.  Similarly,
> optional nested matches would need syntax for graph patterns and ways to
> combine such patterns.
> 
> 
> Proposal (this is a loose description for comment, not a formal definition):
> 
> 1/ Graph "patterns" are grouped by {}
> 
> 2/ A pattern is a list (set) of elements, interpretted as a
> conjunction of elements.
> 
> 3/ Elements are:
>    + patterns
>    + triples, no parenthesises, with trailing dot to terminate/separate
>      (Not allowing N3 style ; and , for the moment).
>    + Constraints, relaxing the separation between
>      triple pattern and constrinats but retaining
>      the familiar mathematical syntax.
>      Leaves open whether 
>    + optional sub patterns
> 
> 4/ Graph patterns can be combined with OR (and AND)
> 
> Other:
> 
> 5/ Prefixes don't have to be defined last, but can occur before use.
>     The only reason for making them first is because it is nice to have
>     SELECT/CONSTRUCT/DESCRIBE/ASK first
> 
> 6/ Constraints: mix with triple patterns, with or without outer ().
> 
> I have mocked it up in javacc and have parsed the examples below.  The
> amount of change in the parser is fairly small because the tokenizer didn't
> change - it was just a matter of writing grammar rules.  The impact on the
> prototype execution engine will be wider, mainly due to the "OR".  (What I'm
> not clear on is the whole (non-syntax) issue of more complex queries and
> mapping to SQL technologies.)
> 
> Examples:
> 
> SELECT * WHERE { ?x ?y ?z }
> SELECT * WHERE { ?x ?y ?z . }
>    Trailing . is optional
>    WHERE is actually unnecessary for a grammar.
> 
> SELECT ?name ?mbox
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> WHERE  { ?x  foaf:name  ?name .
>          ?x  foaf:mbox  ?mbox }
> 
> SELECT ?name ?mbox
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> WHERE  { ?x foaf:name  ?name .
>          OPTIONAL { ?x  foaf:mbox  ?mbox } }
> 
> Could use [] for optional:
> SELECT ?name ?mbox ?shoe
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> WHERE  { ?x foaf:name  ?name .
>          [ ?x  foaf:mbox  ?mbox .
>            ?x  foaf:shoeSize  ?shoe ]
>        }
> 
> Depending on what the outermost grammar production is (element vs pattern),
> we require outer {} or not for things like OR:
> 
> // Outer rule is "element"
> SELECT * WHERE { ?x :p ?z } OR { ?x :q ?z }
> 
> // But this is a bit confusing
> SELECT * WHERE { ?x :p ?z . { ?a :a ?x } OR { ?a :a ?x } }
> 
> // Outer rulke is "pattern"
> {} at all times
> SELECT * WHERE { { ?x :p ?z } OR { ?x :q ?z } }
> 
> SELECT * WHERE { ?x :p ?z .
>                  { { ?a :a ?x } OR { ?a :a ?x } }
>                }
> 
> SELECT * WHERE { ?x :p ?z . ?z < 42 }
> SELECT * WHERE { ?x :p ?z . ?z < 42 . ?a :q ?z }
> 
> With javacc, lookahead gloablly 1 (but locally 2 for optional things like
> trailing dots and allowing commas in various places), I found this works.
> 
> We could mandate outer () on expressions:
> 
> SELECT * WHERE { ?x :p ?z . (?z < 42) }
> 
> Personally, I prefer leaving layout to the application writer, ie. don't
> mandate outer ().
> 
> It is possible to write strange queries like "OR {}", "WHERE OPTIONAL {}"
> but I suggest we keep a fully general grammar for now and leave aside
> whether to ban any non-queries in the grammar until have a full set of
> semantics for the query language.  We can then decide on grammar
> enhancements to make things clearer.
> 
>      Andy
> 

[1] http://www.w3.org/1999/02/26-modules/dist/Federate-1.tar.gz
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.