- From: Graham Klyne <gk@ninebynine.org>
- Date: Tue, 19 Oct 2004 10:44:43 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: www-archive <www-archive@w3.org>
At 22:26 18/10/04 +0100, Seaborne, Andy wrote: >>Yes indeed! I case of uncertainty, I'd advocate the former. It's >>generally easier to add missing features than to remove superfluous ones, >>I think. > >My observation is that many people think the same ... until it comes to >the doing it early bit! The production of the working draft was >fascinating - everybody was keen to "publish whatever we had" - make it a >lightweight thing - until they came to read it (notes: this proves people >never read things beforehand - like for F2F meetings :-) . Then each >person had "a few extras and improvements" and they were all different! >Each on its own was no big deal - together thay made for extensive revisions. > >Your right about minimal - its just there's differences in what's >minimal. The usual (unspoken) driver at the moment is minimizing >implementation work (a very slippery slope IMHO) and the companion >preserving existing investements ("my way works, why change?" except >someone else has a different worable solution!!!). It's never said like >that but behaviours suggest this. This is true. I myself am guilty of this. But I do recognize that many of the things I mentioned in my comments are really considerations for future work. Some touchstones I sometimes use are: - does the proposed minimum in some sense close off any possibility that I'd like to see included? Does it allow me to add my feature as a private extension without breaking the core - will software with my private extension still honour the minimum core semantics properly? (Corollory: it may be better to include a well-considered, simple extension mechanism than a single additional feature. Extensions can be standardized later.) - does the desired extra feature really need to be interoperable? For example, I mentioned that one of my proposals could be implemented by local query rewriting: this suggests quite strongly that the extension does not *need* to be interoperable. - does the desired extra feature really need to be interoperable at Internet scale? It may be that there are small communities who can agree bilaterally or multilaterally to deploy some extension. But if that extension needs to be recognized by entities who cannot reasonably have private agreements in order to be useful, then there's a stronger case for standardization. Maybe I'm just stating the obvious here. And if everyone agrees that a feature is useful, there may be a case for including it anyway. Many of my suggestions were offered in the latter spirit. In short, I don't think that SPARQL is seriously restricted in utility if none of my suggested additions are included: I mention them (early) for consideration, no more. Minimizing implementation work is good, but I suppose a variation of someone's (Einstein?) famous comment is applicable: implementation should be as simple as possible, but no simpler. Clearly, SPARQL in particular has to tread a fine line between implementation complexity and operational efficiency. At this stage, it's probably better to focus on features that impact gross efficiency (query size limits, etc.) than features that expand expressivity/capability. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Received on Tuesday, 19 October 2004 10:28:15 UTC