- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 25 Aug 2008 20:05:41 +0000 (UTC)
On Mon, 25 Aug 2008, Ben Adida wrote: > Ian Hickson wrote: > > The Database stuff was mostly driven by requests from large Web > > application authors (including, for example, GMail), who wanted to be > > able to offer their services even while their users were offline. > > However, it's pretty clear that this need comes from technically capable > folks, not from "the bulk of users," right? The need from the bulk of > users is, at best, "I'd like to access my email offline." Right, it came from a group of folk who clearly described their problem (you can't browser GMail offline, you can't use Google Reader offline, every time you query the user's data in the server-side database, you have to do a network round-trip) and their requirements (e.g. has to work for Web apps, has to work for a variety of application types, has to work offline, has to be able to support full-text search, has to be able to support structured data, has to be synchronisable). I have no idea what problem RDFa is trying to solve. I have no idea what the requirements are. If you want this seriously considered for HTML5, please write a clear and concise e-mail that explains what the needs are. > So my question is: what would it take to convince you that we need > something more generic than the one-off solutions you and others have > been suggesting? I have no idea what problem you're trying to solve, so it's hard for me to answer this question. > > We have to address problems that people know they have, or would agree > > they have if told they had them, because people won't spend any effort > > to address problems they don't think they have. > > So, just to be clear, how does that link up with SQL-in-browser? When > you say "people," do you mean web publishers / application builders? Users. One of the problems, for instance, was that they could not access their GMail while offline. > > The word "problem" doesn't appear once in the ccREL paper. Where is > > the statement of what ccREL is trying to solve? > > Well, the exact word doesn't have to appear, does it? Here are the first > two sentences of the introduction: > > "This paper introduces the Creative Commons Rights Expression Language > (ccREL), the standard recommended by Creative Commons (CC) for > machine-readable expression of copyright licensing terms and related > information. ccREL and its description in this paper supersede all > previous Creative Commons recommendations for expressing licensing > metadata." That's not a problem statement, sorry. It's a description of what it does, but it doesn't say why anyone needs that. > From this it's pretty clear that we're trying to express copyright > licensing information (with all of the sub-fields it implies and all the > possible data types we might license) in machine-readable form. I know _what_ you're trying to do, it's _why_ you're trying to do it that matters. > A one-page answer? That's only possible if you're willing to accept > premises like "RDF is a good way to express interoperable data on the > web." The one-page answer should be explaining why you need to express interoperable data on the Web in the first place. It shouldn't even mention RDF. RDF is part of a proposed solution, it's not part of the problem. > Imagine trying to convince someone about SQL-in-browser when that > someone doesn't believe that SQL is the right approach, rather that it > should be XML object and XPath. Can you do that in one page? The point isn't to convince me about the solution. The point is to convince me that there is a problem at all, so that we can consider what solutions might exist. > But without a baseline, you're sending me on a fool's errand. I'm trying my best to explain to you how you can get somewhere here. This is a good faith effort at trying to help. If you think my advice is somehow intended to waste your time then I can't help you. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 25 August 2008 13:05:41 UTC