Re: [widgets] Test suite full coverage of mandatory aspects in the PC spec, was Re: OMTP BONDI Reference Implementation fully compliant against mandatory PC tests
Hi Marcos, The latest PC test results for Apache Wookie (incubating) are: 165 tests 16 ignored 17 failures 132 passes Failed: dc,d4,an,co,za,bv,rd,b2, ao,cp,cj,af,e8,bl,bm,bn,zz (though the last four test cases may be in error; see previous email) Ignored (not automatically tested - doesn't indicate failure): ds, e4, e5, e6, e7, z1, z2, e1, df, dr, d5, dt, dg, d6, e2, e3 Is there a particular format you need the submission of test results to be in? S On 28 Nov 2009, at 22:36, Marcos Caceres wrote: Hi, On Sat, Nov 28, 2009 at 9:05 PM, David Rogers david.rog...@omtp.org wrote: Dear all, I am very pleased to be able to announce that OMTP's BONDI Reference Implementation for Windows Mobile is now fully compliant to the 165 mandatory tests available for the W3C Widgets 1.0: Packaging and Configuration specification (proposed for CR #2). The test results can be found here: http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html Congrats to the BONDI team :) Many thanks to Toby Ealden, Christian Breitschwerdt and Marcos Caceres for their outstanding efforts on this. We look forward to working with you all on having another interoperable implementation to help achieve full release of the specification. Just wanted to add that last Friday I added the last remaining tests to give us full coverage of all the MUST assertions in the PC test suite. There may be some tests we need to add in the future, but, as editor, I am generally satisfied with the level of coverage we currently have. As noted in another email [2], we still need to add the optional tests to allow us to progress to PR (as requested by the Director of the W3C... again, any help with these tests is greatly appreciated). I am hopeful that other implementers will work with the WG to achieve interoperability across the widget specs by providing us with test suite results and means of verifying those results (and helping us improve the test suite). I'll be moving the implementation report [1] to the W3C on Monday (and I'll add the Widgeon tests). Also, Opera has released it's first set of test results for our internal implementation currently as part of [1]. We have no date yet as to when this implementation will be publicly available, however. Kind regards, Marcos [1] http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0998.html -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] Test suite full coverage of mandatory aspects in the PC spec, was Re: OMTP BONDI Reference Implementation fully compliant against mandatory PC tests
Hi Scott Scott Wilson wrote: Hi Marcos, The latest PC test results for Apache Wookie (incubating) are: 165 tests 16 ignored 17 failures 132 passes Failed: dc,d4,an,co,za,bv,rd,b2, ao,cp,cj,af,e8,bl,bm,bn,zz (though the last four test cases may be in error; see previous email) Ignored (not automatically tested - doesn't indicate failure): ds, e4, e5, e6, e7, z1, z2, e1, df, dr, d5, dt, dg, d6, e2, e3 Is there a particular format you need the submission of test results to be in? yes, I've created a results format: results testsuite = http://dev.w3.org/2006/waf/widgets/test-suite/; product = wookie result for=test-id verdict=fail | pass/result !-- FOR EXAMPLE: result for=cd verdict=failfailed because xyz was returned instead of zyx/result result for=zz verdict=pass/ -- results If you can provide me with a wookie.xml file, then I will include it in the results in the implementation report. Also, if the W3C has set up CVS access for you, you will be able to control your own result set (which is ideal). If the W3C has not yet set up CVS access for you, you need to talk to our team contact (Steven Pemberton steven.pember...@cwi.nl) and he can sort that our for you. Hope that helps, Marcos
Re: [widgets] Interface published
On Nov 25, 2009, at 15:52 , Marcos Caceres wrote:
If the http://www.w3.org/TR/widgets-apis/#the-preferences-attribute was
mandatory, which I think it should be since many widgets I've come across
rely
on **setPreferenceForKey** and **preferenceForKey** conventions, wouldn't it
be
sensible to put the interfaces all into this **preference** [Web
storage](http://www.w3.org/TR/webstorage/) mechanism?
Consider read-only keys like:
widget.getItem(name)
widget.getItem(nameShort)
widget.getItem(authorEmail)
widget.getItem(licencseHref)
However, a generic getItem might have been nice (and extensible)
Wow yeah, why did we never think of that? In fact, we could replace all of our
APIs with this one:
interface DoEverything {
any getItem(in DOMString itemName);
void setItem(in DOMString itemName, in any itemValue);
any doStuff(in Function stuffToBeDone);
}
That way everything would be nice and extensible! Just look:
Instead of:
widget.name
you have:
widget.getItem(name)
and instead of:
widget.aplixExtension
you have:
widget.getItem(aplixExtension)
Revolutionary? Well, if you're in business selling keyboards and RSI relief,
maybe.
Though perhaps ideally when you did a `widget.getItem`, you received the JSON
representation of the XML fragment. Though I'm not entirely sure if there is
a
standard way to map XML onto JSON. You might as well canonicalise the whole
`config.xml` as a JSON string bound to **widget.config**. There, simple. Or
`innerXML` if a JSON translation isn't possible.
There isn't a standard mapping from XML to JSON, but there have been
experiments mapping the Infoset to JSON. Good luck using that here!
All of these things seem like more work. Right now all that is done is that we
map to what's in the configuration table after P+C has run. That's information
that the UA must already have, and can trivially provide — a conversion of the
kind you describe would be more work for implementers, would force authors to
duplicate work that the UA has already done, and would be more complex to
specify. I'm sorry, what was the expected value we would get for that?
We could expose more things, but no one asked for them. If people ask for them,
we can expose them in 1.1. It's not complicated.
--
Robin Berjon - http://berjon.com/
Re: [selectors-api] querySelector with namespace
On Nov 26, 2009, at 15:07 , Lachlan Hunt wrote: Jonathan Watt wrote: Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. That's because you're not reading what Jonathan has been saying. He said xml:id was just the example that drew his attention to the fact that the selectors API can't do namespaces. He points out, rather correctly, that there is no reason that Web content shouldn't be able to process XML and present the processed information to the user. The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Not supporting prefix resolution in selectors is silly, and so far I have yet to see a reason not to do it that isn't grounded in religion. -- Robin Berjon - http://berjon.com/
Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
On Nov 27, 2009, at 15:50 , Arthur Barstow wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is December 2. We support publishing this document. -- Robin Berjon - http://berjon.com/
Re: [widgets] test-suite, default xml:lang
Hi Cyril,
On Nov 27, 2009, at 11:29 , Cyril Concolato wrote:
As a clarification can you tell me what would be the name value for the
following config documents assuming the user locale is en only (no *)
Note that if the user locale (by which I assume you mean what the user agent
starts with, e.g. what the user can configure, and which the specification
calls the unprocessed locales list) contains just {en}, the user agent
locales will be {en, *}. See
http://dev.w3.org/2006/waf/widgets/#algorithm-to-derive-the-user-agent-local.
It's a nitpick, but it's the reason why your results are correct below when
Step 7 is run.
--
Robin Berjon - http://berjon.com/
Re: [selectors-api] querySelector with namespace
Robin Berjon wrote: On Nov 26, 2009, at 15:07 , Lachlan Hunt wrote: Jonathan Watt wrote: Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. That's because you're not reading what Jonathan has been saying. He said xml:id was just the example that drew his attention to the fact that the selectors API can't do namespaces. Yes, I know what he said. The point is that since he agrees that xml:id can't be used in practice on the web, and because even if it could, the ID selector would be good enough, it's not really a compelling, real-world use case for *why* namespace resolution is needed. And other than xml:id, he didn't clearly describe any other use cases at all. He points out, rather correctly, that there is no reason that Web content shouldn't be able to process XML and present the processed information to the user. The question is not and should not be about proving why it shouldn't be able to process XML with namespaces. The question is about why is it worth spending any more time, money and effort than we already have developing a solution for namespace prefix resolution? That is the question that namespace proponents have continually failed to address, and is why I have so far not deemed the issue worthy of significantly more of my time. The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Please clearly explain what one of those real-world things are, where selectors without namespaces is inadequate. In fact, if you could show some real world examples of where sites are switching from selectors api to xpath for the namespace support, or using some other work around, that would go a long way towards understanding what the use cases are, and what problems really need to be solved, as well as help in determining whether or not the problems are significant enough to be worth addressing. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] element-based localization
On Nov 27, 2009, at 20:55 , Marcos Caceres wrote: On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Really? I wouldn't have thought so. There's a difference between you can have xml:lang there and it is meaningful to have xml:lang there (or on its ancestors). You can have xml:lang on widget, but the widget element cannot really be localised (you can't have two, choosing between them depending on locale). It's not a huge difference, but putting localisable: yes on widget would confuse me. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I think that this is even more confused than the original :) To clarify, I think you need to make the same distinction I made above re can have xml:lang and supports being localised. Otherwise you get sentences like elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, to which I can only reply ebbeh?. How about: The xml:lang attribute can be used on any element in order to indicate which language is used in the content and attribute values of that element. Its value is inherited, such that if an element has an xml:lang attribute, all of its descendants are considered to be in that language as well, unless they specify their own xml:lang attribute. Note that an element can indicate that it is in no specific language by setting xml:lang to the empty string, irrespective of whether any of its ancestors has an xml:lang attribute. Some of the elements in the widgets namespace are defined to be localisable. This means that they will be processed in a specific manner if they have an xml:lang value (directly or through inheritance), as described in detail in Step 7. WDYT? -- Robin Berjon - http://berjon.com/
Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
On Mon, Nov 30, 2009 at 3:15 PM, Robin Berjon ro...@berjon.com wrote: On Nov 27, 2009, at 15:50 , Arthur Barstow wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is December 2. We support publishing this document. Opera supports publishing this document. -- Marcos Caceres http://datadriven.com.au
Re: [selectors-api] querySelector with namespace
On Nov 30, 2009, at 15:38 , Lachlan Hunt wrote: The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Please clearly explain what one of those real-world things are, where selectors without namespaces is inadequate. In fact, if you could show some real world examples of where sites are switching from selectors api to xpath for the namespace support, or using some other work around, that would go a long way towards understanding what the use cases are, and what problems really need to be solved, as well as help in determining whether or not the problems are significant enough to be worth addressing. Well, the fact of the matter is that no matter how much energy one might spend pointing out the issues, you'll still come back and say that we don't have a case where the problems are significant enough to be worth addressing. So where do we go from here? There are quite a few services out there that return XML — it would be disingenuous to pretend otherwise. The addition of x-site requests to the stack makes these even more available. XHR supports XML natively, including namespace. Selectors support namespaces natively. Implementations already support that — exposing it at the API level is hardly a massive cost. So apart from saying that all of these are wrong, or saying that XML, XHR, Selectors aren't part of the web stack I can hardly see where your argument is going. Some people did try to specify over-engineered and useless mechanisms based on getting prefixes from a Node. I've been tracking this since this group exists, and I have yet to see a convincing argument that it can't be done simply. Show me a case in which there is a genuine issue, and we might have an informed discussion. -- Robin Berjon - http://berjon.com/
Re: [selectors-api] querySelector with namespace
Robin Berjon wrote: There are quite a few services out there that return XML — it would be disingenuous to pretend otherwise. The addition of x-site requests to the stack makes these even more available. XHR supports XML natively, including namespace. Selectors support namespaces natively. Implementations already support that — exposing it at the API level is hardly a massive cost. So apart from saying that all of these are wrong, or saying that XML, XHR, Selectors aren't part of the web stack I can hardly see where your argument is going. No-one is disputing the fact that those tools exist and that they could be used for XML with namespaces. But are those tools being used in ways that utilise namespaces in useful ways, such that having them exposed at the selector API level would be either useful or even necessary? How about we take a look at some public website APIs using XML that could be suitable for use in cross site requests, and see which, if any, could possibly benefit from supporting prefixes in this API? Twitter: http://apiwiki.twitter.com/Twitter-API-Documentation Does not use namespaces at all, would not benefit from it being added to this API. Flickr: http://www.flickr.com/services/api/ Again, does not use namespaces at all. Validator.nu: http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface http://wiki.whatwg.org/wiki/Validator.nu_XML_Output This does use namespaces in the XML version of it's API. It nests fragments of the XHTML markup within the message and extract elements. These tag names don't clash with any in XHTML, and so they can be selected without bothering about namespaces, or by using a selector like messageserrorelaboration To select any of the XHTML itself, it's easy enough to use a selector like: errorelaboration div or infomessage code The source element does clash with the source element in HTML5, but it can be easily and unambiguously selected using messagessource. So, even if a script opted for the XML output, there is no clear dependency on using namespaced selectors here. Besides, all of those APIs mentioned also offer JSON output, which is much more optimised for use in JavaScript environments where cross site requests will be most common. So what other sorts of APIs do you have in mind which would greatly benefit from namespace support in selectors API? It would help if you could find some other APIs and illustrate with some real world sites that use them, where namespace-supporting APIs are utilised for good reasons on the client side. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[widgets] PAG Launched for Widgets 1.0: Access Requests Policy (WARP) spec
From: ext Ian Jacobs i...@w3.org Date: November 30, 2009 12:08:22 PM EST Subject: PAG Launched for WebApps Working Group Regarding Widgets 1.0: Access Requests Policy ... In accordance with the W3C Patent Policy [0], W3C has launched a Patent Advisory Group (PAG) to advise the W3C on a patent disclosure by Apple [1] relating to the Widgets 1.0: Access Requests Policy Specification [2]. The PAG is governed by the following charter: http://www.w3.org/2009/11/widgets-pag-charter ... [0] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exception [1] http://www.w3.org/2004/01/pp-impl/p72 [2] http://www.w3.org/TR/2009/WD-widgets-access-20090618/
Re: [WARP4U] WARP with UPnP
On 20 Nov 2009, at 17:12, Marcin Hanclik wrote: As discussed on the yesterday's call, I committed to CVS the WARP spec with the section about local network (required for UPnP use cases) at: http://dev.w3.org/2006/waf/widgets-access-upnp/ Clearly there are usage scenarios based on technologies other than UPnP for a scheme that allows widgets to declare an intention to access network resources on the local network - simple web services discovered via mDNS/DNS-SD for example. I haven't seen a lot of discussion of this issue recently, apart from Marcin's proposals. If that reflects a general lack of enthusiasm, it would be useful to know if people's reservations are technical in nature, or if the scenarios in question are simply not thought to be common enough? S
Re: [WARP4U] WARP with UPnP
Hi Stephen, On Nov 30, 2009, at 19:13 , Stephen Jolly wrote: On 20 Nov 2009, at 17:12, Marcin Hanclik wrote: As discussed on the yesterday's call, I committed to CVS the WARP spec with the section about local network (required for UPnP use cases) at: http://dev.w3.org/2006/waf/widgets-access-upnp/ Clearly there are usage scenarios based on technologies other than UPnP for a scheme that allows widgets to declare an intention to access network resources on the local network - simple web services discovered via mDNS/DNS-SD for example. I haven't seen a lot of discussion of this issue recently, apart from Marcin's proposals. If that reflects a general lack of enthusiasm, it would be useful to know if people's reservations are technical in nature, or if the scenarios in question are simply not thought to be common enough? There is interest, but it might not be at the top of everyone's priority list. There are indeed technical issues, but those tend to fan the flame of enthusiasm rather than smother it. Note that the above specification is hardly any progress: it is essentially a copy of the WARP specification with very minor modification. Given that you work for the BBC, that the BBC is a W3C member, and that you seem knowledgeable on the topic is there any chance that you could join in to help with this? It would be most helpful. -- Robin Berjon - http://berjon.com/
Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference
Hi Marcin, On Nov 20, 2009, at 18:12 , Marcin Hanclik wrote: As discussed on the yesterday's call, I committed to CVS the WARP spec with the section about local network (required for UPnP use cases) at: http://dev.w3.org/2006/waf/widgets-access-upnp/ What we discussed on the call was actually creating this as a delta specification that would add a way of expressing that access to the local network is requested. I don't think that it's a good idea to copy the rest of the WARP spec since any edit will bring it out of sync. It's also confusing in that it gives the impression that this document defines WARP, or that simply adding a local keyword is enough to make it work. Can you please update this to just be a delta? Thanks, -- Robin Berjon - http://berjon.com/
Re: [widgets] Publishing LC#2 of the WARP spec
On Nov 25, 2009, at 21:32 , Arthur Barstow wrote: During the November 19 widget call [Nov-19], we spent considerable time discussing how to handle requests for new requirements/features but did not reach consensus. There a couple of options to address new requirements and features and we should continue to discuss the options. Actually I think that we had a viable surface area of consensus. We agreed that Suresh was interested in fleshing out a proposal to have different features be made accessible to different sources based on w:access/w:feature, and that if the WG liked the output from Suresh that it will form the basis either for WARP 1.1 (or 2.0, or whatever we want to call it) or for an extension specification (whichever makes most sense, but that has no impact on WARP itself). We also agreed that UPnP was out of scope and would get specified in its own WARP4U extension spec by Marcin. What we did not reach consensus on was whether WARP should have an informative laundry list of arbitrary things that are not in its scope, and might refer to unpublished or unwritten specifications addressing parts of that laundry list. In effect it's silly to delay based on informative text, so if push comes to shove I'll add a laundry list of a bunch of stuff that is excluded from WARP's scope. I'll note that this should not be taken as an endorsement of the process of adding useless information to technical report, just a choice of battles to prevent stalling on silly issues. We can also always remove informative text later on. -- Robin Berjon - http://berjon.com/
[widgets] Reminder: the Widget Interface LC comment period ends December 8
December 8 is the deadline for comments regarding the Last Call Working Draft of the Widget Interface spec: http://www.w3.org/TR/2009/WD-widgets-apis-20091117/ Comments should be sent to: public-webapps@w3.org -Art Barstow Begin forwarded message: From: ext Marcos Caceres marc...@opera.com Date: November 17, 2009 11:50:04 AM EST To: public-webapps public-webapps@w3.org Subject: [widgets] Interface published Archived-At: http://www.w3.org/mid/4b02d43c.2040...@opera.com Hi all, Widget interface spec ready for publication (Last Call) [1]. Will be out sometime today (if not already published). And test suite files are now online [2]. Enjoy in moderation! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-api/ [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/
Re: [widgets] element-based localization
On Mon, Nov 30, 2009 at 3:41 PM, Robin Berjon ro...@berjon.com wrote: On Nov 27, 2009, at 20:55 , Marcos Caceres wrote: On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Really? I wouldn't have thought so. There's a difference between you can have xml:lang there and it is meaningful to have xml:lang there (or on its ancestors). You can have xml:lang on widget, but the widget element cannot really be localised (you can't have two, choosing between them depending on locale). It's not a huge difference, but putting localisable: yes on widget would confuse me. Agreed. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I think that this is even more confused than the original :) To clarify, I think you need to make the same distinction I made above re can have xml:lang and supports being localised. Otherwise you get sentences like elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, to which I can only reply ebbeh?. How about: The xml:lang attribute can be used on any element in order to indicate which language is used in the content and attribute values of that element. Its value is inherited, such that if an element has an xml:lang attribute, all of its descendants are considered to be in that language as well, unless they specify their own xml:lang attribute. Note that an element can indicate that it is in no specific language by setting xml:lang to the empty string, irrespective of whether any of its ancestors has an xml:lang attribute. Some of the elements in the widgets namespace are defined to be localisable. This means that they will be processed in a specific manner if they have an xml:lang value (directly or through inheritance), as described in detail in Step 7. WDYT? I *really* like it; you never fail to impress Mr Berjon :) ... but the first para should just be a Note: (we don't want to have that in as normative text because it describes behavior specified in the XML spec... hence, I would add as specified in [XML], bla bla bla). The second paragraph can serve as a normative definition to which all localizable via xml:lang link to. Can you live with that? If you can, I have added the above to the spec. With that, we are ready to go to CR so please give me your consent. -- Marcos Caceres http://datadriven.com.au
Re: Renaming WebDatabase and WebSimpleDB
Hi Nikunj, @2009-11-26 02:00 -0800: [...] Here's my suggestion: 1. WebDatabase be renamed to WebSQLDatabase 2. WebSimpleDB be renamed to ISAM Database Level 1 I don't think ISAM Database Level 1 is an improvement. As an alternative title, I suggest Web Key-Value Database. As far as what's wrong with ISAM Database Level 1: For one thing, the term ISAM is not actually mentioned anywhere in the text of the current draft itself. Also, I would wonder whether most people in this group and on this mailing list know what ISAM is. I didn't. I had to look it up to see what it means. I think it would be preferable to have a title that doesn't reference a technology term that'll be obscure to most readers. I also suggest not including Level 1 in the title unless/until we also publish a Level 2 draft. And as far as the Web part of the title, the benefit of retaining that in the title is that it's a convention that's developed as a shorthand to indicate that a draft is for a technology that's intended to be part of the Web platform -- and to be implemented in Web clients/user-agents -- as opposed to being something intended to be implemented on the server side, or as opposed to something intended to be implemented for some other purpose than for delivering and interacting with content on the Web. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: Renaming WebDatabase and WebSimpleDB
I agree with Mike, but I'd also note that Web Key-Value Database could easily be confused with WebStorage given that it also uses a Key-Value model. Which brings up another point: Maybe WebStorage should be renamed as well? On Mon, Nov 30, 2009 at 8:20 AM, Michael(tm) Smith m...@w3.org wrote: Hi Nikunj, @2009-11-26 02:00 -0800: [...] Here's my suggestion: 1. WebDatabase be renamed to WebSQLDatabase 2. WebSimpleDB be renamed to ISAM Database Level 1 I don't think ISAM Database Level 1 is an improvement. As an alternative title, I suggest Web Key-Value Database. As far as what's wrong with ISAM Database Level 1: For one thing, the term ISAM is not actually mentioned anywhere in the text of the current draft itself. Also, I would wonder whether most people in this group and on this mailing list know what ISAM is. I didn't. I had to look it up to see what it means. I think it would be preferable to have a title that doesn't reference a technology term that'll be obscure to most readers. I also suggest not including Level 1 in the title unless/until we also publish a Level 2 draft. And as far as the Web part of the title, the benefit of retaining that in the title is that it's a convention that's developed as a shorthand to indicate that a draft is for a technology that's intended to be part of the Web platform -- and to be implemented in Web clients/user-agents -- as opposed to being something intended to be implemented on the server side, or as opposed to something intended to be implemented for some other purpose than for delivering and interacting with content on the Web. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: Renaming WebDatabase and WebSimpleDB
Jeremy Orlow jor...@chromium.org, 2009-11-30 14:46 -0800: I agree with Mike, but I'd also note that Web Key-Value Database could easily be confused with WebStorage given that it also uses a Key-Value model. True but we know the distinction is that Web Storage does not use a database. Or I guess to put it more precisely, it's not exposed to applications as a database. I do realize that to casual readers that distinction might not be obvious to readers. But we always have a tradeoff between, on the one hand, trying to make spec titles precise, and on the other hand, keeping the titles concise. I think the Storage vs. Database distinction is one that makes a pretty good tradeoff. Which brings up another point: Maybe WebStorage should be renamed as well? I don't think we should unless somebody can come up with a concise way of qualifying it more. I guess Web Local and Session Storage might be more precise, but I'm not sure whether most people would consider that an improvement. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: Renaming WebDatabase and WebSimpleDB
On Nov 30, 2009, at 8:20 AM, Michael(tm) Smith wrote: Hi Nikunj, @2009-11-26 02:00 -0800: [...] Here's my suggestion: 1. WebDatabase be renamed to WebSQLDatabase 2. WebSimpleDB be renamed to ISAM Database Level 1 I don't think ISAM Database Level 1 is an improvement. As an alternative title, I suggest Web Key-Value Database. As far as what's wrong with ISAM Database Level 1: For one thing, the term ISAM is not actually mentioned anywhere in the text of the current draft itself. Also, I would wonder whether most people in this group and on this mailing list know what ISAM is. I didn't. I had to look it up to see what it means. I think it would be preferable to have a title that doesn't reference a technology term that'll be obscure to most readers. I admit I also found the term ISAM initially confusing (I had to look it up). I think it is an improvement on Simple, since it draws a distinction that is objective and based on the technology. But it would be nice if we could find a less obscure technology-based term in the index, ideally one that is used and explained in the spec. I'm not sure what that would be though. I also suggest not including Level 1 in the title unless/until we also publish a Level 2 draft. It's really best not to use Level terminology at all and just use version numbers, if versioning is even needed. Level is supposed to have some kind of distinction from version but I think it is more confusing than clarifying here. Regards, Maciej
Re: CfC - publish Selectors API as CR
On Thu, 26 Nov 2009, Anne van Kesteren wrote: The CSS WG relatively recently dropped this requirement. Developer builds are now sufficient. I was not really in favor, but most of the group was. I'm not really in favour of dropping this requirements either. The whole point of beta builds is to find out if something is implementable; it's not evidence that it is, which is what we are supposed to be looking for. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Renaming WebDatabase and WebSimpleDB
Hi Mike, Good to see some comments on this. On Nov 30, 2009, at 8:20 AM, Michael(tm) Smith wrote: Hi Nikunj, @2009-11-26 02:00 -0800: [...] Here's my suggestion: 1. WebDatabase be renamed to WebSQLDatabase 2. WebSimpleDB be renamed to ISAM Database Level 1 I don't think ISAM Database Level 1 is an improvement. As an alternative title, I suggest Web Key-Value Database. Key-Value by itself doesn't mean much. Certainly, it could be confused with Web Storage and hence would not be appropriate. Do you have a better suggestion that does not involve shuffling more names? As far as what's wrong with ISAM Database Level 1: For one thing, the term ISAM is not actually mentioned anywhere in the text of the current draft itself. This objection can be easily remedied. Also, I would wonder whether most people in this group and on this mailing list know what ISAM is. You are probably right that people on this WG don't all know what ISAM is. However, if you look at Microsoft's first review of WebSimpleDB, you will find it there. So there are more people besides myself who know about ISAM and think this spec is primarily talking about that. I didn't. I had to look it up to see what it means. I think it would be preferable to have a title that doesn't reference a technology term that'll be obscure to most readers. A generic term could mean something too broad and a specific term might be arcane. To the extent that the arcane term is the most used for a certain meaning and can be easily understood by readers with minimal help, the specific term sounds more useful. Would you agree that it was easy to understand what ISAM means when you spend 5 minutes reading the Wikipedia article on ISAM [1]? I also suggest not including Level 1 in the title unless/until we also publish a Level 2 draft. I am not sure that is necessary. Knowing fully well how many people have asked for requirements that are difficult to accommodate in the first rev, it is important, although not essential, for readers to know that more APIs could be layered on top. I expect this spec to be expanded in a manner similar to DOM. If that means not numbering anything now, then so be it. I can easily remove the Level suffix. And as far as the Web part of the title, the benefit of retaining that in the title is that it's a convention that's developed as a shorthand to indicate that a draft is for a technology that's intended to be part of the Web platform -- and to be implemented in Web clients/user-agents -- as opposed to being something intended to be implemented on the server side, or as opposed to something intended to be implemented for some other purpose than for delivering and interacting with content on the Web. I certainly don't think that is necessary considering that this API is likely to be used on servers just as much as on clients. At least one participant has stated that in this DL [2]. Therefore, I don't see the benefit of putting a Web prefix. Nikunj http://o-micron.blogspot.com [1] http://en.wikipedia.org/wiki/ISAM [2] http://www.w3.org/mid/4af9cbee.2060...@sitepen.com
Re: Renaming WebDatabase and WebSimpleDB
On Nov 30, 2009, at 3:14 PM, Michael(tm) Smith wrote: Jeremy Orlow jor...@chromium.org, 2009-11-30 14:46 -0800: I agree with Mike, but I'd also note that Web Key-Value Database could easily be confused with WebStorage given that it also uses a Key- Value model. True but we know the distinction is that Web Storage does not use a database. Do we make naming decisions considering just us WG members as its audience or that of the general public? I think the general public is well within its rights to treat Web Storage as a persistence technology that seems to be like Key-Value database. I want to emphasize here that I think key-value in the title misses the subtlety - it is the use of index sequential access that is at the heart of WebSimpleDB, and not key-value storage. Nikunj http://o-micron.blogspot.com
Re: Renaming WebDatabase and WebSimpleDB
Web-Indexed-Storage On Mon, Nov 30, 2009 at 4:52 PM, Nikunj R. Mehta nikunj.me...@oracle.comwrote: On Nov 30, 2009, at 3:14 PM, Michael(tm) Smith wrote: Jeremy Orlow jor...@chromium.org, 2009-11-30 14:46 -0800: I agree with Mike, but I'd also note that Web Key-Value Database could easily be confused with WebStorage given that it also uses a Key-Value model. True but we know the distinction is that Web Storage does not use a database. Do we make naming decisions considering just us WG members as its audience or that of the general public? I think the general public is well within its rights to treat Web Storage as a persistence technology that seems to be like Key-Value database. I want to emphasize here that I think key-value in the title misses the subtlety - it is the use of index sequential access that is at the heart of WebSimpleDB, and not key-value storage. Nikunj http://o-micron.blogspot.com
Re: Renaming WebDatabase and WebSimpleDB
Nikunj R. Mehta nikunj.me...@oracle.com, 2009-11-30 16:49 -0800: [...] A generic term could mean something too broad and a specific term might be arcane. To the extent that the arcane term is the most used for a certain meaning and can be easily understood by readers with minimal help, the specific term sounds more useful. Would you agree that it was easy to understand what ISAM means when you spend 5 minutes reading the Wikipedia article on ISAM [1]? Sure. But I don't think from that it necessarily follows that having ISAM is the best thing to have in the title. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: WebDatabase review: SQLResultSetRowList
On Mon, 31 Aug 2009, Nikunj R. Mehta wrote: SQLResultSetRowList The item() method may take a long time to process. Shouldn't this have an asynchronous version with a callback? The ability to randomly access rows in the row set increases the likelihood that the item operation will take an arbitrarily long time. Plus, supporting random access is very expensive on limited memory devices. The UA is expected to prefetch all of the data before invoking the callback, in the async case, to avoid this problem. Offer next() and previous() methods that returns the next and previous row respectively. Offer absolute() and relative() call that may fail. See java.sql.ResultSet.absolute() and java.sql.ResultSet.relative(). I'll leave this for a future version. The length attribute could require accessing all the rows, which would use too much memory on limited memory devices. The implementation can use TOO_LARGE_ERR in those cases. Specify that the SQLResultSetRowList that resulted from a call to SQLTransaction.executeSql() can only be accessed during the execution of the associated SQLStatementCallback It is intended to be permanently accessible. Property names on result sets are based on column names used in the query or defined in the view/table. These name sources (colmns, selections) are case insensitive but the row object would have to use case-sensitive names. Is there a way that objects can be accessed without case insensitivity? In the API, the names are case-sensitive (using the case returned by the database). Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [web databases] about rowids
On Wed, 2 Sep 2009, João Eiras wrote: Hi everyone. 1) Currently, SqlResultSet.insertId is defined as a integer. This would prevent user agents to use an underlying database engine that does not rely on integers for rowids. For instance, both SQLite, MS Access, Informix use integers it seems, DB2 uses a transparent type 17 bytes big, Oracle uses strings, Java JDBC uses byte[]. For the sake of compatibility, it would probably be better to make insertId either a string, or in the case of lack of agreement, a implementation defined type, which is not desirable. Since we're now requiring a sqlite-compatible backend, integer is right, no? 2) insertId only stores one row id. That's not very helpful for the case of a INSERT INTO table(...) SELECT ... dml. Considering that the query could produce an arbitrary number of rowids, the insertId field should probably be a SqlResultSetRowList, or an array. insertId is supposed to expose sqlite3_last_insert_rowid, which doesn't seem to support returning an array. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webdatabase] Minor Clarification Needed in Processing Model
On Thu, 3 Sep 2009, Lachlan Hunt wrote: Hi, In step 10 of the processing model, it states: Queue a task to invoke the error callback, if it is not null, with a newly constructed SQLError object that represents the last error to have occurred in this transaction. Rollback the transaction. Any still-pending statements in the transaction are discarded. Can you clarify this statement so that it's clearer that it's referring to the transaction's error callback, and not a statement error callback in executeSql. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [web databases] changeVersion error reporting
On Fri, 4 Sep 2009, João Eiras wrote: Database.changeVersion expects oldVersion and newVersion arguments. The Database also specifies a version attribute. The transaction steps tell to fail the transaction due to the failed preflight condition if oldVersion does not match the current database version. Meanwhile, the callbacks have been made optional, and rightly so. So: - if the author does not use the callbacks, there no error reporting that the preflight condition failed - the version check can be done synchronously when changeVersion is called because the Database object has immediate access to that value, and it's much more convenient for the author to just get an exception (like INVALID_STATE_ERR) than to have to go through the entire callback process just to realize later that the transaction failed due to the mismatched version. It also spares the user agent from creating and executing a transaction that WILL fail. To solve these issues, I would suggest doing immediate synchronous validation of the version when changeVersion is called, throwing an exception on error, and drop that step from the preflight operations. On Thu, 3 Sep 2009, Michael Nordman wrote: If the version is stored in the database file itself, as is with webkit's impl for example, the database object does not have immediate access to that value. On Fri, 4 Sep 2009, João Eiras wrote: So that was one of the motives to add the creation callback on openDatabase I presume. In either case, before the script gets a Database object, a version check needs to be made during openDatabase, so the value can be cached inside the Database object, to be used for changeVersion, the version property and subsequent transactions. The version might change in the background, so the value can't be cached. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [web databases] SQLStatementErrorCallback
On Fri, 4 Sep 2009, Dumitru Daniliuc wrote: When talking about statement error callbacks (point #6, section 4.3.2), the spec says: 1. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 2. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. What should happen if the callback doesn't return anything (undefined)? Should we jump to the transaction error callback? Can/should we clarify this in the spec too? If it doesn't return false, then the second step you quote above (numbered 3 in the spec) applies, no? I don't understand how this is unclear. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebDatabase bug tracking
On Mon, 21 Sep 2009, Nikunj R. Mehta wrote: On Sep 21, 2009, at 2:51 PM, Ian Hickson wrote: On Mon, 21 Sep 2009, Nikunj R. Mehta wrote: Can we have another component added to Bug tracker for WebDatabase? I feel the need to track several bugs and am not at all comfortable with asynchronous email (with long delays in between). The e-mails I still have pending are listed here: http://www.whatwg.org/issues/#websql From the current WD, If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives) or wha...@whatwg.org (subscribe, archives), or submit them using our public bug database. All feedback is welcome. I would like to have a consistent place to report this and that would seem to be W3C. You can report issues to the public-webapps list, yes. The draft is co-developed by the WHATWG and this WG, so feedback can go to several places. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webdatabase] wording on Parsing and processing SQL statements section
On Fri, 25 Sep 2009, João Eiras wrote: In section 4.2 Parsing and processing SQL statements, point 2 starts as Replace each ? placeholder but then says later Note: Substitutions for ? placeholders are done at the literal level, not as string concatenations. By using the word replace, that execution step may cause confusion, as I've seen, about people thinking it might be related to some sort of concatenation, although the specification clearly clarifies that's not the intended result. I would reword step 2 and the clarification as: Bind each ? placeholder with the value of the argument in the arguments array with the same position. (So the first ? placeholder is bound the first value in the arguments array, and generally the nth ? placeholder gets bound by the nth value in the arguments array.) By binding, the result of the query must be the same as if the arguments had been literally replaced on the sql string, although this later practice is not recommended because it may risk SQL injection attacks. Using Bind for Replace makes it much more clear. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [EventSource] Comments to the current draft
On Tue, 27 Oct 2009, SULLIVAN, BRYAN L (ATTCINW) wrote: Re The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.: what is meant by Push SMS? Does this refer to OMA Push, i.e. the service enabler defined by the Open Mobile Alliance (OMA)? As I am the chair of the OMA Content Delivery (CD) working group, and as convener and a key contributor to the work on OMA Push, I would like to discuss the potential synergy between Server Sent Events and OMA Push, as complementary mechanisms in an overall server sent events framework. But first I need to be sure of what the Push SMS term refers to. Re Such formats could include systems like SMS-push; for example servers could use Accept headers and HTTP redirects to an SMS-push mechanism as a kind of protocol negotiation to reduce network load in GSM environments.: This statement should be clarified. What's meant by use Accept headers and HTTP redirects to an SMS-push mechanism is unclear. If the client is offline, webapp servers can use OMA Push API's (including the OMA Push Access Protocol) to initiate delivery of Push messages to the user agent, including the text/event-stream MIME type (since OMA Push supports any MIME type). The latest version of the OMA Push specification (OMA Push 2.2) defines an abstract interface via which web applications can register for OMA Push events, and this interface can be supported through a Javascript-callable API (in development). I've tried to address these, as discussed here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8359 Re User agents must act as if the connection had failed due to a network error if the origin of the URL of the resource to be fetched is not the same origin as that of the first script when the EventSource() constructor is invoked.: what this means is unclear (at least to me). It relies on terms defined in HTML5. You can see a version of this that includes cross-references properly in the WHATWG complete.html file: http://www.whatwg.org/specs/web-apps/current-work/complete.html (WARNING: very large file - some browsers can't handle this file) Is this essentially referring to the same-domain restriction, i.e. an eventsource() domain must be the same as the script source domain? To a first approximation, yes. What is the first script (and does this imply that only one eventsource() call is possible for a webapp)?. The first script is a concept used to scope certain concepts that apply to APIs, like the current origin, the current URL character encoding, etc, as defined in HTML5 (and in answer to your parenthetical question: no). Re If such a resource (with the correct MIME type) completes loading (i.e. either the entire HTTP response body is received, or the connection is closed somehow, whether by the server or by a network error), the user agent must reset the connection.: this would seem to say after each response, the connection must be reset (the entire HTTP response body is received). This seems inefficient, if dropping the HTTP connection is what is meant. Not only could the data connection be then dropped, but at least the eventual HTTP connection reestablishment is a significant expense, resulting in a high overhead of TCP chatter. It would seem that keeping the connection alive and letting the server decide when to drop the connection would be a better approach. Re HTTP 204 No Content, and 205 Reset Content responses are equivalent to 200 OK responses with the right MIME type but no content, and thus must reset the connection.: same comment as above, seems very inefficient if what's meant is dropping the HTTP connection. I've tried to clarify these, as per: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8190 Re HTTP 200 OK responses that have a Content-Type other than text/event-stream (or some other supported type): other supported type I suppose means some arbitrary MIME type supported by the user agent. Are there any practical limitations on what MIME types can be supported? Well, they have to be formats that are relevant; I mean, image/png wouldn't make much sense. Beyond that, I don't believe so. Re When a user agent is to reset the connection, the user agent must set the readyState attribute to CONNECTING, queue a task to fire a simple event named error at the EventSource object,... : firing an error is strange given that to reset the connection is a normal step of event handling as described above when the entire HTTP response body is received or HTTP 204 No Content is received. These are all basically error conditions in the context of API. Re The task source for any tasks that are queued by EventSource objects is the remote event task source.: can this statement be explained (with references as needed)? What is the remote event task source? See HTML5 for details on these terms. Cross-references
Re: Renaming WebDatabase and WebSimpleDB
I like the name, except the Web part. Why is it necessary? I argued that it will not be limited to user agents only. Would it really be bad to call it Index Sequential Database? On Nov 30, 2009, at 5:34 PM, Frederick Hirsch wrote: how about Indexed Sequential Web Database, losing the acronym, even if familiar to those who work with databases? (not web-indexed, however...) regards, Frederick Frederick Hirsch Nokia On Nov 30, 2009, at 8:11 PM, ext Michael Nordman wrote: Web-Indexed-Storage On Mon, Nov 30, 2009 at 4:52 PM, Nikunj R. Mehta nikunj.me...@oracle.com wrote: On Nov 30, 2009, at 3:14 PM, Michael(tm) Smith wrote: Jeremy Orlow jor...@chromium.org, 2009-11-30 14:46 -0800: I agree with Mike, but I'd also note that Web Key-Value Database could easily be confused with WebStorage given that it also uses a Key- Value model. True but we know the distinction is that Web Storage does not use a database. Do we make naming decisions considering just us WG members as its audience or that of the general public? I think the general public is well within its rights to treat Web Storage as a persistence technology that seems to be like Key-Value database. I want to emphasize here that I think key-value in the title misses the subtlety - it is the use of index sequential access that is at the heart of WebSimpleDB, and not key-value storage. Nikunj http://o-micron.blogspot.com Nikunj http://o-micron.blogspot.com
Re: Renaming WebDatabase and WebSimpleDB
Since this API is about a transactional database, it is better to call it a database instead of storage. Storage also means that there is no automated index maintenance since it is only about storage and not about arrangement of records or their indexing. Nikunj On Nov 30, 2009, at 5:11 PM, Michael Nordman wrote: Web-Indexed-Storage On Mon, Nov 30, 2009 at 4:52 PM, Nikunj R. Mehta nikunj.me...@oracle.com wrote: On Nov 30, 2009, at 3:14 PM, Michael(tm) Smith wrote: Jeremy Orlow jor...@chromium.org, 2009-11-30 14:46 -0800: I agree with Mike, but I'd also note that Web Key-Value Database could easily be confused with WebStorage given that it also uses a Key-Value model. True but we know the distinction is that Web Storage does not use a database. Do we make naming decisions considering just us WG members as its audience or that of the general public? I think the general public is well within its rights to treat Web Storage as a persistence technology that seems to be like Key-Value database. I want to emphasize here that I think key-value in the title misses the subtlety - it is the use of index sequential access that is at the heart of WebSimpleDB, and not key-value storage. Nikunj http://o-micron.blogspot.com Nikunj http://o-micron.blogspot.com
Re: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November
On Wed, 4 Nov 2009, Jonas Sicking wrote: I know we had this conversation before, and I'm not even sure which side of the issue I was on at the time, but given the amount of confusion at the TPAC meeting yesterday, I think we should consider renaming the Web Database spec. It seems clear at this point that the API will in all likelyhood forever be SQL based, so I propose that we include SQL somewhere in the name, for example Web SQL Database or some such. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
