- From: Ivan Mikhailov <imikhailov@openlinksw.com>
- Date: Fri, 13 Mar 2009 22:08:30 +0600
- To: Chimezie Ogbuji <ogbujic@ccf.org>
- Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
Chimezie, > I don't think I agree that optimization and implementation effort (which is > a direct consequence of the complexity introduced by more expressive query > forms such as sub-selects) should *not* be a factor. I'd say even more. Optimization and implementation effort must be ignored as decision factor, "must" in its ultimate, RFC 2119 meaning. The reason is that language users are much more numerous than language implementations. A book composer do not pay much attention to the author's comfort when it conflicts with the comfort of readers. A public transport dispatcher would ignore personal wishes from train crew --- the railway is built not for their needs. We're in similar circumstances. IMHO, there's a short list of excuses for excluding a user-friendly feature from spec: 1. The feature saves less time than it costs for everybody to study the thicker spec. 2. The feature conflicts with a more useful feature (say, blocks the optimization due to fundamental reason). 3. We're too busy with more requested features and accurately postpone something to the next round, providing reserved words and grammar constructs in current spec. Please correct if I've missed something. Best Regards, Ivan Mikhailov OpenLink Software. P.S. re. sub-selects, to be specific. Indeed, LET with clauses GROUP BY, ORDER BY, LIMIT, OFFSET, DISTINCT and options will replace sub-selects, formally speaking. I joust doubt to say whether it is more comfortable than sub-selects --- it gives same number of keywords and parenthesis.
Received on Friday, 13 March 2009 16:09:21 UTC