- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Tue, 9 Nov 2004 00:50:26 +0000
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mon, Nov 08, 2004 at 02:50:36PM -0000, Andy Seaborne wrote: > http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0199.html > > waiting for the editors to announce if there are any document changes. > > I don't actually see any decision in the last telcon minutes > > > > > http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0210.html > > > > All three. Or just # (c.f. common in scripting languages). +1 for just # > > ISSUE: Commas or no commas > > I've already seen user confusion when they tried to use ','s inside > > WHERE (s, p, o) and omitting them outside with SELECT ?x ?y. I've > > mentioned this many times as likely to happen. It's hard to remember. > > And I have replied on IRC and elsewhere. You don't like the approach of > allowing different styles of writing; I see that the effect is so small > on the implementer (and is done in RDLQ) as to not justify picking one. > Syntax is a value judgement - see other DAWG syntax issues. My (admittedly small) experience is that having multiple syntax choices makes it hard for beginners. I usually write RDQL in fully verbose mode (a, b, c), (a, b, d) etc. and users who started with my examples tend to get a bit stumped when they see the compact form. > > ISSUE: OPTIONAL or []s > > I've asked several times to pick just one of these. The WG looked > > favourably at F2F on a syntax containing the latter only. This > > is related to the more general need for a grouping construct - not > > needed at all if nested optionals are ditched. > > This is slipping into language design by syntax: I think that rejecting > a feature (nested optionals) based purely on a minor syntax issue is a > very bad basis for a decision. We still need a grouping construct if OR is allowed. I'm not sure that the syntax is that minor an issue, though I agree that the expressivity - complexity should have priority. - Steve
Received on Tuesday, 9 November 2004 00:50:32 UTC