Re: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September
On Sep 1, 2009, at 19:31 , Laxmi Narsimha Rao Oruganti wrote: LINQ is a hard one to push as LINQ again ties back to Microsoft only (single vendor). As a Microsoft employee I am super excited about LINQ, but as standards advocate LINQ is not the right one. Unless Microsoft puts some effort in standardizing the LINQ and promotes few other vendors go for it (much like ODBC), I would not vouch for it in web standards. On the other hand, I have heard of efforts in having LINQ like stuff in Java. I don't have an agenda to push for LINQ, but I don't think that the reasons you quote eliminate it as an option — many successful standards started off as a single vendor solution and were later submitted for consideration by a standards group. I guess what I'm saying is: since you don't like the SQL-based approach that is currently being explored, and since you have a wealth of research into better alternatives, why not look into contributing them? -- Robin Berjon - http://berjon.com/
Re: [widget] relax NG schema
On Wed, 02 Sep 2009 11:14:42 +0200, Robin Berjon ro...@berjon.com wrote: On Sep 1, 2009, at 19:19 , Marcos Caceres wrote: On Tue, Sep 1, 2009 at 6:07 PM, Robin Berjonro...@berjon.com wrote: http://dev.w3.org/2006/waf/widgets-schema/widgets.rng Good. Cool. So I've made a few changes: - renamed it to .rnc since it's in RNC and not RNG - modularised it as explained earlier — so you can be happy because it's centralised to a single directory, but it's not a centralised file - removed the built-in extensibility and used NVDL instead, which is more appropriate and maintainable - added support for WARP - removed a bunch of bugs - added a bunch of tests (examples from the spec) to make sure it's okay Awesome! Thanks Robin! I've now run a check on the schema based on the tests and it seems to be correct. I'd appreciate review! I believe RNC should be served as application/relax-ng-compact-syntax rather than text/plain. -- Simon Pieters Opera Software
RE: to publish a new WD of the DOM3 Events spec; deadline Sep 4
Hi, ACCESS supports this publication. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Friday, August 28, 2009 5:29 PM To: public-webapps; www-...@w3.org Subject: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4 This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html 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 Sep 4. Although rev 1.50 is currently the latest version [1] and it says the date is July 20, the CVS history indicates Doug modified the document today. Doug - please update the date. DOM folks - please see [2] for a brief overview of WebApps' CfC process. -Regards, Art Barstow [1] http://dev.w3.org/cvsweb/2006/webapi/DOM-Level-3-Events/html/DOM3- Events.html [2] http://www.w3.org/2008/webapps/wiki/ WorkMode#Consensus_and_Call_for_Consensus Begin forwarded message: From: ext Doug Schepers schep...@w3.org Date: August 28, 2009 11:08:01 AM EDT To: member-weba...@w3.org member-weba...@w3.org Subject: New WD of DOM3 Events? Archived-At: http://www.w3.org/mid/4a97f2d1.6010...@w3.org Hi, WebApps WG- We have been working on the DOM3 Events spec for a while, and I have made quite a few edits recently. While it's certainly not complete, I believe it is at a stage where it would benefit from greater public review. I would like to ask the chairs to put the question to the WG on publishing a new Working Draft of the spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3- Events.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widget] relax NG schema
Simon Pieters wrote: I've now run a check on the schema based on the tests and it seems to be correct. I'd appreciate review! I believe RNC should be served as application/relax-ng-compact-syntax rather than text/plain. Yeah, but for now it's better for us humans so we can just view the content in the browser. Having to download the file, open it in editor, etc, etc. is a PITA. Once the document matures and stabilizes, then we will serve it properly.
Re: [widget] relax NG schema
On Wed, Sep 2, 2009 at 12:19 PM, Marcos Caceresmarc...@opera.com wrote: Simon Pieters wrote: I've now run a check on the schema based on the tests and it seems to be correct. I'd appreciate review! I believe RNC should be served as application/relax-ng-compact-syntax rather than text/plain. Yeah, but for now it's better for us humans so we can just view the content in the browser. Having to download the file, open it in editor, etc, etc. is a PITA. Once the document matures and stabilizes, then we will serve it properly. +1 for waiting to stabilizes Xmlizer
Re: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September
On Sep 1, 2009, at 1:31 PM, ext Laxmi Narsimha Rao Oruganti wrote: I am fine this going for public working draft and hence get reach more people/community for review. OK. From: Robin Berjon [mailto:ro...@berjon.com] ... just to make sure that we are clear on what you are objecting to: the CfC is for a Working Draft (what's more, the first) to be published. This by no means entails ratification by W3C, it simply reflects where the group is on that topic. Correct; thanks for clarifying this Robin. -Regards, Art Barstow
Re: [widget] relax NG schema
On Sep 2, 2009, at 12:19 , Marcos Caceres wrote: Yeah, but for now it's better for us humans so we can just view the content in the browser. Having to download the file, open it in editor, etc, etc. is a PITA. Once the document matures and stabilizes, then we will serve it properly. More importantly, that's an issue under the control of the W3C systeam so it's not something that this WG has much control over :) -- Robin Berjon - http://berjon.com/
[web databases] about rowids
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. 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. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
[widgets] Draft agenda for 3 September 2009 Voice Conf
Below is the draft agenda for the 3 Septemmber Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps@w3.org is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements 3. PC spec ED: http://dev.w3.org/2006/waf/widgets/ TSE: http://dev.w3.org/2006/waf/widgets/Overview_TSE.html a. Comments from PFWG submitted by Michael Cooper http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 0843.html b. IRI/URI normalization: request for I18N Core WG review http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 0644.html c. CC requirements - what if no one implements them? 4. widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. Storage thread by Scott Wilson http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 0783.html WebStorage ED: http://dev.w3.org/html5/webstorage/ 5. WARP spec a. LC comments from Marcin Hanclik http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 0844.html 6. URI Scheme spec: proposal to publish LCWD http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ 7. AOB
Re: [Widget URI] Bugs (1)
On Jul 26, 2009, at 23:18 , Marcin Hanclik wrote: The below 1. could be correct if assumed host is beefdead. I am not sure, however, whether in the widget-URI rule, we use the authority rule from RFC3986, because it is meant to be opaque as specified here: http://dev.w3.org/2006/waf/widgets-uri/#the-widget-uri-scheme The idea was for the example to show an authority identifier (because it is allowed). The idea is that it comes from the UA, and is opaque (even though it has a string representation that matches the authority production). I've added a comment to indicate that that is the intent. Thanks! -- Robin Berjon - http://berjon.com/
Re: [WebIDL] Feedback on the August 30 Editor's draft
Hi Travis, 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) This looks to be a reasonable solution for the problem Andrew and Cameron discussed about to me. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Is this for the accessor (getter/setter) introduced in ECMAScript 5? Regards, - Shiki Okasaka On Tue, Sep 1, 2009 at 2:07 PM, Travis Leitheadtra...@microsoft.com wrote: Cameron et al., I have a couple pieces of feedback on this draft. Let me start by saying that this is a wonderful spec—much needed by the working group, and much appreciated by the IE team in relation to the additional clarity it provides for interpretation of other specs. Before I launch into the specific feedback, let me explain the principle behind my thinking: make the DOM binding for JavaScript as extensible as possible. I’d like to ensure that within reason, there is sufficient language binding to make the DOM as extensible and customizable as possible for web developers. For example, web developers that want to customize DOM behavior via one of its APIs should only have to do so at most once (or several times if the API is a mixin). Most of the design decisions for IE8’s DOM prototypes follow this principle. 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) My first comment here is that this is overly complicated. I don’t quite follow why the mixin prototype object is defined to exist one level up from the object instance. This pretty much ensures that it’s impossible to override the behavior of a mixin property (operation) on any scope larger than instance-level. For example, a developer would like to customize the behavior of addEventListener by replacing the native property with his/her own behavior, which ultimately invokes the native addEventListener API via apply. To do this and comprehensively cover every case where a webpage could use addEventListener, the web developer must override every instance in the DOM. This is unmanageable for any practical application. Rather, if the mixin properties were defined to exist higher-up in the prototype chain, then much more “coverage” can be obtained by one replacement. Since the mixin may appear on other interfaces, the scenario is not a single-point of replacement, but in all likelihood, a manageable number. I propose simplifying the mixin design substantially. I would like to see TargetInterface implements MixinInterface; be interpreted as merging each property/operation that is defined on the MixinInterface interface with the properties/operations on the TargetInterface. Treat mixins as literally “mixing in” to their associated interface. This likely implies that no interface object nor associated interface prototype object need be created in the ECMAScript binding. Where the MixinInterface interface is implemented by AnotherInterface, it’s properties/operations are merged to that interface as well (creating a copy of the property/operations on AnotherInterface). I believe that design is simpler for web developers to understand, and also increases the utility of extending the functionality of typical mixins (like EventTarget). Today, no browser implementation that I’m aware of handles this consistently, and thus the risk to change the spec is very low. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Again, from the extensibility point of view, it’s concerning to me that properties as defined on an interface are not actually represented as properties on the corresponding interface prototype object! Rather, the spec as it is currently written, flattens all properties to the object instance (which appears to coincide with Safari’s behavior for properties). With the current approach, properties (i.e., those defined with ‘attribute’ in the WebIDL) cannot be overridden (or replaced) on anything other than object instances themselves. A key scenario for IE8 was the ability to customize or replace the functionality of innerHTML globally for all elements. Thus, we provided a property for innerHTML on the most general element type we had (Element—yes I know it’s not the correct prototype hierarchy—we’re working on that J). Web developers can customize and extend that property in one place for far-reaching impact with little effort. Naturally, properties on prototypes are meaningless when invoked directly (they need an instance object ‘this’ reference), which is why IE8 and Firefox require the use of call/apply to be used when direct-invoking these. Opera does not appear to define properties at any level in their prototype chain, yet respects the web author’s intent to override them (again, at any point in the hierarchy). I favor IE, FF, and Opera’s extensibility over Safari’s simplicity on this point. I propose defining properties (not just operations) on
Re: [webdatabase] Transaction Locks
+ Dumi who's working on this for Chromium and has dealt with some of these issues recently, IIRC. On Mon, Aug 31, 2009 at 4:37 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: Hi, In the processing model [1], step 2 says: If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. It's not clear if the spec requires the transaction to fail to open in the case that it can't yet obtain an appropriate lock, or whether the spec just allows that as an implementation decision. According to our developer, the way we've implemented it is that we will always create a new transaction and run the transaction callback, but the SQL statements themselves will be queued up and run whenever the lock becomes available. There is no timeout that will cause it to invoke the error callback. Is this acceptable, or should the transaction callback not be run while there is another lock in effect on the database? [1] http://dev.w3.org/html5/webdatabase/#processing-model -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [webdatabase] Transaction Locks
I can't speak for the spec authors, but I can tell you what WebKit does at the moment. We acquire a lock before we run the transaction callback, but just like you, we do not have a timeout that invokes the error callback. So it seems to me like overall our implementations should behave similarly (we wait for the lock before running the transaction callback, you wait for it before running the first statement). 1. Is it OK to start a transaction callback without getting a lock first? I don't see why not, as long as the transaction produces the correct result. 2. Do we need to have a timeout on acquiring locks (or anything else, for that matter) when opening transactions? I don't think so. As a user, I'd rather have a sometimes slow web page than a sometimes failing one. dumi On Mon, Aug 31, 2009 at 4:37 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: Hi, In the processing model [1], step 2 says: If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. It's not clear if the spec requires the transaction to fail to open in the case that it can't yet obtain an appropriate lock, or whether the spec just allows that as an implementation decision. According to our developer, the way we've implemented it is that we will always create a new transaction and run the transaction callback, but the SQL statements themselves will be queued up and run whenever the lock becomes available. There is no timeout that will cause it to invoke the error callback. Is this acceptable, or should the transaction callback not be run while there is another lock in effect on the database? [1] http://dev.w3.org/html5/webdatabase/#processing-model -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
Hi Mark, On May 22, 2009, at 15:25 , Mark Baker wrote: I'm curious to learn where the requirement that Must not allow addressing resources outside a widget came from? Can you point to a precedent for such a restriction in any other protocol? I remember TimBL writing something to the effect of Anywhere you can use a URI, you can use any URI, possibly in his design issues, but I can't find a reference right now. The idea is that as currently defined, the URI scheme can only point to resources contained inside the widget. Wherever you use a widget: URI, you can also use other URI schemes such as http: or file: (i.e. there's no restriction on the content) but depending on your security settings it might not be retrieved and if executed it probably won't have access to the same APIs. The widget: URI comes with a guarantee that you're pointing inside the widget, which is a nice, clean, sandboxed world (which incidentally might also be signed). I also don't understand what that bit about run on the web means in the intro. Yeah, neither do I. I've tried to make the abstract clearer. Thanks! -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
Hi Larry, On May 22, 2009, at 17:29 , Larry Masinter wrote: If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? Inter-widget communication is a use case that can be tackled later — this is left as an open door. The UUID has been dropped since indeed without that it is not needed. Thanks! -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On May 22, 2009, at 20:21 , Mark Baker wrote: Ah, right, I didn't realize it was related to a discussion Marcos and I had last year; http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/thread.html#msg50 I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? Reading that thread I don't see a consensus emerging one way or another, and a lot of options appear to be considered that seem to be out of scope (or too close to the metal) for this specification. I see some arguments around using file: that could be used, but none seem to explain how it could be without entirely precluding other file: access (which could potentially be needed) or minting special names (e.g. a special file host), which strikes me as a bad idea. Would you care to outline what specifically you had in mind? -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On May 23, 2009, at 19:21 , Mark Baker wrote: Right. That's the same point Arve made. I don't see a problem with it. Sure, a widget will be able to discover an implementation detail of its widget container - the base URI - but it's still up to the container to permit or deny access to other resources from that widget when asked to dereference it, whether the widget discovered the URI via a mechanism such as the one you describe, or even if it simply guessed it. Calling it an implementation detail doesn't make it one. Say I have a script in which I need to identify resources that I'm currently using from within the widget. Since I don't want to have to care how the designers linked them in, I'll use their absolute URIs to compare them. If implementation A returns http://magic-widget-host.local/dahut.svg , and implementation B file:///special-widget-mount/dahut.svg, and C gives me made-up:/dahut.svg we don't exactly have interoperability. This gets more interesting once you bring the localisation mechanism from P+C into play, whereby the Zip relative path and the relative URI are different when you have multilingual content. -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, 02 Sep 2009 16:26:19 +0200, Robin Berjon ro...@berjon.com wrote: Reading that thread I don't see a consensus emerging one way or another, and a lot of options appear to be considered that seem to be out of scope (or too close to the metal) for this specification. I see some arguments around using file: that could be used, but none seem to explain how it could be without entirely precluding other file: access (which could potentially be needed) or minting special names (e.g. a special file host), which strikes me as a bad idea. In my opinion, the file: protocol needs to be avoided *at all costs*. User agents have, in over fifteen years of trying, not managed to agree on how to implement it interoperably, varying from how to encode drive and host names (on some operating systems) to how you deal with path traversal and content protection issues. Neither have they managed to agree on what origin means, or whether it is acceptable to accept active content in this context. We could spend man-years in trying to come up with something interoperable and be exactly where we were yesterday. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
Jean-Claude, On May 26, 2009, at 17:38 , Jean-Claude Dufourd wrote: 0- the author needs a way to point to resources within the widget package Correct. 1- the URI scheme will never be used by the author (written by Marcos), the author will use relative URIs for resources within the widget. Partly correct. Authors can use it in content (for consistency), they are merely discouraged from doing so. However when identifying a document through the DOM (or any other way that deals in absolute URI references) then it will naturally be used. 2- the browser will have to resolve the relative URI to an absolute URI because of the DOM spec Not because of the DOM spec. It so happens that the DOM exposes the absolute URI — which is the smart thing to do and not an aspect of the DOM that is contested by anyone. Even without the DOM the implementation would likely deal in absolute URI references — however the fact that interests us here is that users have access to that information, that there are valid use cases for scripting against it, and therefore that it must be predictable. , hence a possible vulnerability by divulging private information (e.g. actual name of current user in file: URI example of Apple Dashboard widgets) to scripts running in the widget. That is just one of the many arguments that have been made against reusing existing schemes. Other schemes always involve hacks to work around their semantics or the minting of special names within them (typically for their authority, but possibly for their first steps as well if we consider mounts on localhost). Creating a new scheme avoids reuse-by-brutal-shoehorn. Mandating the implementation in the widget UA of a URI resolution that does not divulge private information to the widget scripts is sufficient to ensure that the vulnerability mentioned in 2- does not happen. The proposed URI scheme could be suggested as an option, but not more. How do you define private information? How does that translate into an actual URI that can be compared character by character in different implementations? It's not clear enough to be a mandate (since it's not clear what implementers must do), and even if it were it seems unlikely to solve the issue. Furthermore, suggesting the proposed URI as an option seems to introduce yet more optionality which would further hurt interoperability. My understanding is that 3- mandates a particular URI scheme which will never be used by the author and will never be exchanged between two implementations. That is incorrect. The URI can and will be used in script. -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On May 27, 2009, at 10:15 , Jean-Claude Dufourd wrote: Arve Bersvendsen a écrit : The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) JCD: I am unconfortable with such thinking that standards makers somehow know better than implementors (and I am a standard maker). As it happens, Arve is an implementer. This is a case where you would expose the problem in an informative part of the spec and propose (not mandate) a working solution to implementers. I don't see how that would work — how does an optional specification help interoperability. If it is not seen by the author But, as has been explained before, it is. -- Robin Berjon - http://berjon.com/
Last-call comment: Widgets 1.0: APIs and Events
Re: http://www.w3.org/TR/2009/WD-widgets-apis-20090818/ This document appears to be mis-titled. Although it claims This specification defines APIs and events ..., I can see nothing that I recognize as defining an event. #g
Re: [widget] relax NG schema
On Wed, Sep 2, 2009 at 1:30 PM, Robin Berjonro...@berjon.com wrote: On Sep 2, 2009, at 12:19 , Marcos Caceres wrote: Yeah, but for now it's better for us humans so we can just view the content in the browser. Having to download the file, open it in editor, etc, etc. is a PITA. Once the document matures and stabilizes, then we will serve it properly. More importantly, that's an issue under the control of the W3C systeam so it's not something that this WG has much control over :) Actually, I think we can add our own .htaccess files. Though I've not tried AddType. Anyway, we will cross that bridge when we need to. -- Marcos Caceres http://datadriven.com.au
Re: Last-call comment: Widgets 1.0: APIs and Events
Hi Graham, On Wed, Sep 2, 2009 at 4:19 PM, Graham Klyneg...@ninebynine.org wrote: Re: http://www.w3.org/TR/2009/WD-widgets-apis-20090818/ This document appears to be mis-titled. Although it claims This specification defines APIs and events ..., I can see nothing that I recognize as defining an event. Yeah, we published with that name for legacy reasons... we have renamed it to: Widgets 1.0: The widget Interface See: http://dev.w3.org/2006/waf/widgets-api/ WDYT? -- Marcos Caceres http://datadriven.com.au
Re: Request for Comments: FPWD of Widgets 1.0: URI Scheme spec
Hi Moz, On Jun 19, 2009, at 10:02 , mozer wrote: 1) In the same spirit as WARP, it would be interesting to make HTML5 reference, an informative one After careful consideration I believe that you are right — there is no direct normative dependency. It is now informative. 2) Probably the link between authority and opaque-autorithy should be clearer I am not sure what you mean exactly. If there is an authority component, it is considered to be opaque (i.e. devoid of semantics). I went through every occurrence of authority in the draft but am not sure what I would change to satisfy this comment. 3) Update reference to Working Draft 28 May 2009 for Widgets-PC Done (to CR). 4) s/RFC5234/RFC 5234/ Done. I'm not sure to fully understand this requirement [[ Must be independent of any file system Addressing based on this scheme must only map onto Zip relative paths and remain independent of any file system on which the widget may be stored. ]] Does it mean that, it is case insensitive for example ? No, it does not mean that it uses the lowest common denominator of all file systems (that wouldn't leave us with much :) but that it isn't constrained by the FS it's running on and its conventions (e.g. you won't get foo\bar on Windows and foo/bar everywhere else). If it so happens that an implementation of P+C unpacks (as an internal detail) the content of the widgets to a specific on-disk directory, the widget URIs must still work the same way (and if that directory is on a case- insensitive FS, the implementation is in trouble — but that's not our problem). -- Robin Berjon - http://berjon.com/
Re: [Widgets] URI Scheme - URI [+ Scheme]
Hi Marcin, On Jul 26, 2009, at 20:51 , Marcin Hanclik wrote: 1. renaming the Widgets 1.0: URI Scheme specification to Widgets 1.0: URI (or Widgets 1.0: Widget URI or so) I've changed it to Widgets 1.0: Widget URIs. Not the most elegant title to grace the delicate shores of TR but we've seen worse. 2. adding widget-scheme = widget rule 3. modifying the existing rule widget-URI = widget: // [ authority ] / zip-rel-path [ ? query ] [ # fragment ] to widget-URI = widget-scheme :// [ authority ] / zip-rel-path [ ? query ] [ # fragment ] Done (except that it's different from the above because it references the i-variants). 4. updating the related sections, e.g. adding section on scheme registration (some other document?), splitting text for widget-URI and widget-scheme, since these are different things etc. I've clarified this, and split the text into sub-sections. Indeed the scheme becomes almost a side-note. Thanks! -- Robin Berjon - http://berjon.com/
Re: [webdatabase] changeVersion should allow all callbacks to be optional
On Fri, 28 Aug 2009, Lachlan Hunt wrote: The spec currently requires the first 2 callbacks for the changeVersion method, while the 3rd is optional. The spec should make all of the callbacks optional so authors don't resort to specifying empty functions when they don't actually need to do anything with it. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webdatabase] changeVersion should allow all callbacks to be optional
On Fri, 28 Aug 2009, Lachlan Hunt wrote: FWIW, this API is insanely complicated and has way too many callbacks to keep track of. It's caused me a lot of confusion and makes using it incredibly complex. Yeah. Let me know if you have any better ideas. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webdatabase] changeVersion should allow all callbacks to be optional
On Sep 2, 2009, at 3:12 PM, Ian Hickson wrote: On Fri, 28 Aug 2009, Lachlan Hunt wrote: FWIW, this API is insanely complicated and has way too many callbacks to keep track of. It's caused me a lot of confusion and makes using it incredibly complex. Yeah. Let me know if you have any better ideas. :-) It is a nice way to capture the current situation with the API. On the one hand, experienced and sincere programmers such as Lachy are not able to use the API and on the other hand, we fail to come up with alternatives. I wonder why we are pushing ourselves (and the hordes of people who want to store data in databases) over the metaphorical cliff. I am working on an alternative (non-SQL, and non-callback craziness). It may not be very user-friendly (some waits, some deadlocks), but it is at least more programmer-friendly. Some often talk about the hypothetical Web database programmer as being significantly different from the typical database programmer. However, I am not going to be able to offer much by means of ideas for a type of person that I cannot recognize or understand. I am hoping to have an initial editor's draft ready this week. I hope the WG finds it interesting. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.' Nikunj http://o-micron.blogspot.com
RE: [WebIDL] Feedback on the August 30 Editor's draft
2- property inheritance (regarding 4.4.3 [interface prototype objects]) Is this for the accessor (getter/setter) introduced in ECMAScript 5? Yes and no. Before ES5, browser venders still have ways of getting the getter/setter pair (__defineGetter__/ __lookupGetter__), so the scenario is still relevant. The meta-point is that it's more about being able to improve the utility of extending or replacing the behavior of these properties. -Travis -Original Message- From: Shiki Okasaka [mailto:sh...@google.com] Sent: Wednesday, September 02, 2009 7:10 AM To: Travis Leithead Cc: public-webapps@w3.org; Cameron McCormack; Tony Ross; Adrian Bateman Subject: Re: [WebIDL] Feedback on the August 30 Editor's draft Hi Travis, 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) This looks to be a reasonable solution for the problem Andrew and Cameron discussed about to me. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Is this for the accessor (getter/setter) introduced in ECMAScript 5? Regards, - Shiki Okasaka On Tue, Sep 1, 2009 at 2:07 PM, Travis Leitheadtra...@microsoft.com wrote: Cameron et al., I have a couple pieces of feedback on this draft. Let me start by saying that this is a wonderful spec—much needed by the working group, and much appreciated by the IE team in relation to the additional clarity it provides for interpretation of other specs. Before I launch into the specific feedback, let me explain the principle behind my thinking: make the DOM binding for JavaScript as extensible as possible. I’d like to ensure that within reason, there is sufficient language binding to make the DOM as extensible and customizable as possible for web developers. For example, web developers that want to customize DOM behavior via one of its APIs should only have to do so at most once (or several times if the API is a mixin). Most of the design decisions for IE8’s DOM prototypes follow this principle. 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) My first comment here is that this is overly complicated. I don’t quite follow why the mixin prototype object is defined to exist one level up from the object instance. This pretty much ensures that it’s impossible to override the behavior of a mixin property (operation) on any scope larger than instance-level. For example, a developer would like to customize the behavior of addEventListener by replacing the native property with his/her own behavior, which ultimately invokes the native addEventListener API via apply. To do this and comprehensively cover every case where a webpage could use addEventListener, the web developer must override every instance in the DOM. This is unmanageable for any practical application. Rather, if the mixin properties were defined to exist higher-up in the prototype chain, then much more “coverage” can be obtained by one replacement. Since the mixin may appear on other interfaces, the scenario is not a single-point of replacement, but in all likelihood, a manageable number. I propose simplifying the mixin design substantially. I would like to see TargetInterface implements MixinInterface; be interpreted as merging each property/operation that is defined on the MixinInterface interface with the properties/operations on the TargetInterface. Treat mixins as literally “mixing in” to their associated interface. This likely implies that no interface object nor associated interface prototype object need be created in the ECMAScript binding. Where the MixinInterface interface is implemented by AnotherInterface, it’s properties/operations are merged to that interface as well (creating a copy of the property/operations on AnotherInterface). I believe that design is simpler for web developers to understand, and also increases the utility of extending the functionality of typical mixins (like EventTarget). Today, no browser implementation that I’m aware of handles this consistently, and thus the risk to change the spec is very low. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Again, from the extensibility point of view, it’s concerning to me that properties as defined on an interface are not actually represented as properties on the corresponding interface prototype object! Rather, the spec as it is currently written, flattens all properties to the object instance (which appears to coincide with Safari’s behavior for properties). With the current approach, properties (i.e., those defined with ‘attribute’ in the WebIDL) cannot be overridden (or replaced) on anything other than object instances themselves. A key scenario for IE8 was the ability to customize or replace the functionality of innerHTML globally for all elements. Thus, we provided a property for innerHTML on the most general element type we had (Element—yes I know
Re: [WebIDL] Feedback on the August 30 Editor's draft
On Thu, Sep 3, 2009 at 8:12 AM, Travis Leitheadtra...@microsoft.com wrote: 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Is this for the accessor (getter/setter) introduced in ECMAScript 5? Yes and no. Before ES5, browser venders still have ways of getting the getter/setter pair (__defineGetter__/ __lookupGetter__), so the scenario is still relevant. The meta-point is that it's more about being able to improve the utility of extending or replacing the behavior of these properties. If Web IDL is going to mention the accessor property in ECMAScript, I agree it would be very practical to have accessor properties on the corresponding interface prototype objects. Is there any plan to specify ES5 (or maybe existing ES getter/setter implementation) binding in Web IDL? Best, - Shiki -Travis -Original Message- From: Shiki Okasaka [mailto:sh...@google.com] Sent: Wednesday, September 02, 2009 7:10 AM To: Travis Leithead Cc: public-webapps@w3.org; Cameron McCormack; Tony Ross; Adrian Bateman Subject: Re: [WebIDL] Feedback on the August 30 Editor's draft Hi Travis, 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) This looks to be a reasonable solution for the problem Andrew and Cameron discussed about to me. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Is this for the accessor (getter/setter) introduced in ECMAScript 5? Regards, - Shiki Okasaka On Tue, Sep 1, 2009 at 2:07 PM, Travis Leitheadtra...@microsoft.com wrote: Cameron et al., I have a couple pieces of feedback on this draft. Let me start by saying that this is a wonderful spec—much needed by the working group, and much appreciated by the IE team in relation to the additional clarity it provides for interpretation of other specs. Before I launch into the specific feedback, let me explain the principle behind my thinking: make the DOM binding for JavaScript as extensible as possible. I’d like to ensure that within reason, there is sufficient language binding to make the DOM as extensible and customizable as possible for web developers. For example, web developers that want to customize DOM behavior via one of its APIs should only have to do so at most once (or several times if the API is a mixin). Most of the design decisions for IE8’s DOM prototypes follow this principle. 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) My first comment here is that this is overly complicated. I don’t quite follow why the mixin prototype object is defined to exist one level up from the object instance. This pretty much ensures that it’s impossible to override the behavior of a mixin property (operation) on any scope larger than instance-level. For example, a developer would like to customize the behavior of addEventListener by replacing the native property with his/her own behavior, which ultimately invokes the native addEventListener API via apply. To do this and comprehensively cover every case where a webpage could use addEventListener, the web developer must override every instance in the DOM. This is unmanageable for any practical application. Rather, if the mixin properties were defined to exist higher-up in the prototype chain, then much more “coverage” can be obtained by one replacement. Since the mixin may appear on other interfaces, the scenario is not a single-point of replacement, but in all likelihood, a manageable number. I propose simplifying the mixin design substantially. I would like to see TargetInterface implements MixinInterface; be interpreted as merging each property/operation that is defined on the MixinInterface interface with the properties/operations on the TargetInterface. Treat mixins as literally “mixing in” to their associated interface. This likely implies that no interface object nor associated interface prototype object need be created in the ECMAScript binding. Where the MixinInterface interface is implemented by AnotherInterface, it’s properties/operations are merged to that interface as well (creating a copy of the property/operations on AnotherInterface). I believe that design is simpler for web developers to understand, and also increases the utility of extending the functionality of typical mixins (like EventTarget). Today, no browser implementation that I’m aware of handles this consistently, and thus the risk to change the spec is very low. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Again, from the extensibility point of view, it’s concerning to me that properties as defined on an interface are not actually represented as properties on the corresponding interface prototype object! Rather, the spec as it is currently written, flattens all properties to the object instance (which appears to coincide with Safari’s behavior for properties). With the
