Re: Handling too few arguments in method calls
On Jun 23, 2009, at 02:29 , Jonas Sicking wrote: If we went with option 1, what is the effect of the [optional] flag? I.e. what is the difference between 1 and putting [optional] on all arguments? I'd prefer to go with option 2, but use [optional] in more specs. +1 from me -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Web IDL syntax
On Jun 23, 2009, at 05:41 , Shiki Okasaka wrote: If we are breaking syntax, then it seems more compelling to make “DOMString” be “string”. Maybe we could drop the “in” keyword. Seems better to stick with plain “in” arguments, for compatibility across language bindings, than to also allow “out” and “inout” ones. I'd vote for not changing these, because we already have a lot of IDL out there and it would be a pain to fix it all. Can we make in optional so that new interfaces can be defined without using in? It seems very easy to forget to specify in for each parameter in Web IDL. I like that option, the ability to not use in would be really nice to have. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] Please include a statement of purpose and user interaction expectations for feature
On Jun 2, 2009, at 16:02, Robin Berjon wrote: On Jun 2, 2009, at 14:57 , Henri Sivonen wrote: Please include a corresponding UA requirement to obtain authorization from the user for the features imported with feature. (It seems that the security aspect requires an authorization and doesn't make sense if the dangerous feature are simply imported silently.) As far as I can tell, the spec doesn't currently explain what the UA is supposed to do with the 'feature list' once built. I don't think that that is a good idea. The purpose of feature is to provide a hook through which a widget may communicate with a security policy. What's in the security policy really isn't up to P +C to define (though it certainly should be defined somewhere else). Maybe it could ask the user, as you state, but maybe it could see that the widget was signed by a trusted party, or know that the device doesn't have any sensitive data for a given API, or maybe anything goes on the full moon. I see. The track record with Java APIs doesn't fill me with confidence that the Right Thing will be done, but I guess this is outside the scope of interop-oriented specs. (My current phone asks me every time Google Maps Mobile wants to use the network and doesn't allow me to grant the permission permanently and doesn't ask me when GMM wants to grab my geolocation and send it to Google.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [widgets] Please include a statement of purpose and user interaction expectations for feature
On Jun 23, 2009, at 12:55 , Henri Sivonen wrote: On Jun 2, 2009, at 16:02, Robin Berjon wrote: On Jun 2, 2009, at 14:57 , Henri Sivonen wrote: Please include a corresponding UA requirement to obtain authorization from the user for the features imported with feature. (It seems that the security aspect requires an authorization and doesn't make sense if the dangerous feature are simply imported silently.) As far as I can tell, the spec doesn't currently explain what the UA is supposed to do with the 'feature list' once built. I don't think that that is a good idea. The purpose of feature is to provide a hook through which a widget may communicate with a security policy. What's in the security policy really isn't up to P +C to define (though it certainly should be defined somewhere else). Maybe it could ask the user, as you state, but maybe it could see that the widget was signed by a trusted party, or know that the device doesn't have any sensitive data for a given API, or maybe anything goes on the full moon. I see. The track record with Java APIs doesn't fill me with confidence that the Right Thing will be done, but I guess this is outside the scope of interop-oriented specs. (My current phone asks me every time Google Maps Mobile wants to use the network and doesn't allow me to grant the permission permanently and doesn't ask me when GMM wants to grab my geolocation and send it to Google.) Precisely: defining behaviour would turn us into a UI specification — which we dearly want to avoid. Constant prompting makes for a dreadful UX, that's for sure, but fixing that should be up to UA vendors. At the end of the day, I do however have some confidence that they can do UI much better than anything Java related :) -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] Please include a statement of purpose and user interaction expectations for feature
On Tue, Jun 23, 2009 at 2:44 PM, Robin Berjonro...@berjon.com wrote: Precisely: defining behaviour would turn us into a UI specification — which we dearly want to avoid. yep. Constant prompting makes for a dreadful UX, that's for sure, yep. but fixing that should be up to UA vendors. or rather getting it right (and preferably the first time). At the end of the day, I do however have some confidence that they can do UI much better than anything Java related :) I have confidence that certain vendors could. But the vendor to which Henri alludes, and certain vendors in certain spaces OTOH, we don't have confidence about their abilities. But it really is beyond the scope of a specification like this to say don't drive your users crazy. Our goal should be to avoid requirements written as drive your user crazy. There's apparently a MUST in some HTTP spec for some stupid error case which would effectively mean you must annoy your user whenever you encounter this, thankfully either all browser vendors missed it, or they chose to ignore it. WRT the codecs thing, I'm not sure if it's in the minutes, but iirc the example was mine so as to avoid having something which said like APIs but provided no examples. And yes, granting permissions for features is beyond the scope of this specification.
[XHR] XMLHttpRequest name
Hi, Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? Glen.
Re: [XHR] XMLHttpRequest name
On Tue, 23 Jun 2009 08:46:35 -0400, Glen lonedesign...@yahoo.com wrote: Hi, Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? I don't know. I have a habit of typing XMLHTTPRequest. -- Michael
Alpha Widget checker
Hi, Francois Daoust and I played with creating a widget checker tool that implements some of the conformance checker requirements of the widgets PC spec. The said tool can be experimented with at: http://qa-dev.w3.org:8001/widget/ (an uncool URI that is likely to break in the future) but please note that it is not meant to be reliable or useful in any way at this stage - it's more of a proof of concept than anything else. It's built on top of the architecture used for the mobileOK checker, and the code is available at: http://dev.w3.org/cvsweb/2009/widget-checker/ You can get a rough idea of the things the checker already detected by looking at: http://dev.w3.org/2009/widget-checker/src/org/w3c/mwi/widget/xslt/messages.properties.xml It's not clear yet that either Francois or I would be able to spend much more time on that tool; but feedback, suggestions, or interests in contributing to the development of that tool would all be welcome. Dom
Re: [XHR] XMLHttpRequest name
On Tue, 23 Jun 2009 14:46:35 +0200, Glen lonedesign...@yahoo.com wrote: Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? All I know for sure is that we cannot change this. (I.e. it has been widely deployed and implemented with the current name for nearly a decade.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] XMLHttpRequest name
Yeah, that's what's unfortunate. I just hope that future naming follows a standard. Anne van Kesteren wrote: On Tue, 23 Jun 2009 14:46:35 +0200, Glen lonedesign...@yahoo.com wrote: Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? All I know for sure is that we cannot change this. (I.e. it has been widely deployed and implemented with the current name for nearly a decade.)
Re: [XHR] XMLHttpRequest name
On Tue, 23 Jun 2009 16:17:39 +0200, Glen lonedesign...@yahoo.com wrote: Yeah, that's what's unfortunate. I just hope that future naming follows a standard. I'm afraid there's no standard for naming, but it would be nice to avoid names like XMLHttpRequest in the future, yes. -- Anne van Kesteren http://annevankesteren.nl/
[widgets] [preference element] question on the value attribute
We are wondering about the choice of an attribute to store the value of a preference. We would prefer to use the text content of the preference element for the value of the preference. Is there a good reason that we missed for using an attribute instead ? Thanks JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: [XHR] XMLHttpRequest name
That's surprising. If there are no guidelines, then it won't likely be avoided in future. We'll end up with all sorts of variations. Anne van Kesteren wrote: On Tue, 23 Jun 2009 16:17:39 +0200, Glen lonedesign...@yahoo.com wrote: Yeah, that's what's unfortunate. I just hope that future naming follows a standard. I'm afraid there's no standard for naming, but it would be nice to avoid names like XMLHttpRequest in the future, yes.
Request for comments: Delivery Context Ontology Last Call; Deadline 7 Aug 2009
The UWA WG asked the WebApps WG to review the 16 June LCWD of the Delivery Context Ontology: http://www.w3.org/TR/2009/WD-dcontology-2009061 If you have any comments, please send them to: public-...@w3.org -Regards, Art Barstow Begin forwarded message: From: ext Matt Womer m...@w3.org Date: June 23, 2009 2:22:43 PM EDT Subject: Delivery Context Ontology Last Call The Ubiquitous Web Application Working Group [1] has published the Delivery Context Ontology as a Last Call Working Draft [2] on 16 June 2009: http://www.w3.org/TR/2009/WD-dcontology-20090616/ The changes made in this draft are documented within the draft itself [3] which has listed each of the deleted and added properties and classes. Feedback on this document would be appreciated through 7 August 2009 (updated after publication at WAI-PF's request) via mail to public-...@w3.org. In particular we are requesting review from the following WG's: MMI, HCG (including OMA, and OMTP), and WAI-PF. The Device API and Policy WG and WebApps WG's may also be interested in providing review. The Group made the decision to go to Last Call: http://www.w3.org/2009/04/16-uwawg-minutes.html#item01 No patent disclosures have been made [4]. Thank you! Matt Womer UWA Activity Lead [1] http://www.w3.org/2007/uwa/ [2] http://www.w3.org/TR/2009/WD-dcontology-20090616/ [3] http://www.w3.org/TR/2009/WD-dcontology-20090616/ Overview.html#sec-summary-changes [4] http://www.w3.org/2004/01/pp-impl/40755/status
Re: [widgets] [preference element] question on the value attribute
On Tue, Jun 23, 2009 at 6:16 PM, Jean-Claude Dufourdjean-claude.dufo...@telecom-paristech.fr wrote: We are wondering about the choice of an attribute to store the value of a preference. We would prefer to use the text content of the preference element for the value of the preference. Is there a good reason that we missed for using an attribute instead ? The range of values allowed in attributes is more restrained and easier to parse than text content. This makes it easier to integrate with the Storage interface for preferences in the Widgets AE spec. However, if you have a use case for using the text content of the preference element, then please send it to the WG for consideration. -- Marcos Caceres http://datadriven.com.au
Re: Request for comments: Delivery Context Ontology Last Call; Deadline 7 Aug 2009
Hi, On Tue, Jun 23, 2009 at 8:32 PM, Arthur Barstowart.bars...@nokia.com wrote: The UWA WG asked the WebApps WG to review the 16 June LCWD of the Delivery Context Ontology: http://www.w3.org/TR/2009/WD-dcontology-2009061 The above link should be: http://www.w3.org/TR/2009/WD-dcontology-20090616/ If you have any comments, please send them to: public-...@w3.org -Regards, Art Barstow Begin forwarded message: From: ext Matt Womer m...@w3.org Date: June 23, 2009 2:22:43 PM EDT Subject: Delivery Context Ontology Last Call The Ubiquitous Web Application Working Group [1] has published the Delivery Context Ontology as a Last Call Working Draft [2] on 16 June 2009: http://www.w3.org/TR/2009/WD-dcontology-20090616/ The changes made in this draft are documented within the draft itself [3] which has listed each of the deleted and added properties and classes. Feedback on this document would be appreciated through 7 August 2009 (updated after publication at WAI-PF's request) via mail to public-...@w3.org. In particular we are requesting review from the following WG's: MMI, HCG (including OMA, and OMTP), and WAI-PF. The Device API and Policy WG and WebApps WG's may also be interested in providing review. The Group made the decision to go to Last Call: http://www.w3.org/2009/04/16-uwawg-minutes.html#item01 No patent disclosures have been made [4]. Thank you! Matt Womer UWA Activity Lead [1] http://www.w3.org/2007/uwa/ [2] http://www.w3.org/TR/2009/WD-dcontology-20090616/ [3] http://www.w3.org/TR/2009/WD-dcontology-20090616/Overview.html#sec-summary-changes [4] http://www.w3.org/2004/01/pp-impl/40755/status -- Marcos Caceres http://datadriven.com.au
Re: [XHR] XMLHttpRequest name
On Jun 23, 2009, at 18:19 , Glen wrote: That's surprising. If there are no guidelines, then it won't likely be avoided in future. We'll end up with all sorts of variations. We already have all sorts of variations, we're surviving it. It's not so surprising at all considering how deeply independent invention is woven into the web's evolution. We frequently have naming discussions but they generally involve voting someone off the island, and that's just not nice. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] [preference element] question on the value attribute
On Jun 23, 2009, at 18:16 , Jean-Claude Dufourd wrote: We are wondering about the choice of an attribute to store the value of a preference. We would prefer to use the text content of the preference element for the value of the preference. Is there a good reason that we missed for using an attribute instead ? If by text content you mean actual text content, then there is no difference whatsoever between what can be stored in an attribute value and the text content (as per DOM 3 textContent) of an element — at least not semantically. If by text content you mean structured content, then we're talking about turning the preference system into an XML storage system since most XML constructs could appear there. Do you mind clarifying which one it is you are wondering about? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Why I don't attend the weekly teleconference (Was: Input on the agenda)
On Jun 23, 2009, at 4:44 PM, Ian Hickson wrote: On Tue, 23 Jun 2009, Shelley Powers wrote: OK, I hereby volunteer to be the editor of the specification related to HTML Tables, and to the part of the specification supposedly addressing issues of semantic metadata. I'm serious -- where do I sign up, and when can I get editing rights? You already have editing rights. Just start writing. You don't have to ask anyone's permission. There is plenty of precedent for this; when a spec of sufficient quality comes up that replaces a section of the HTML5 spec, I remove the text in HTML5 and instead point (if appropriate) to the new text. This has happened with XMLHttpRequest, the Selectors API, Window (which was later remerged in), the URL parsing and resolving sections, the Content Sniffing section, and for a number of other documents that I still edit (Web Socket API, Web Socket Protocol, Web Storage, Server-sent Events, and Web Workers). I know this is from a separate conversation, but I ask because it is relevant to me in the context of Web Storage. Would it be possible to edit the Web Storage API draft to include the proposed [1] programmable HTTP cache [2] in it? I suppose the precedent is commit-then-review. Is that practice relevant in this case? What software and configuration do I need to commit? Nikunj http://o-micron.blogspot.com [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0341.html [2] http://www.oracle.com/technology/tech/feeds/spec/bitsy.html
Re: Why I don't attend the weekly teleconference (Was: Input on the agenda)
On Tue, 23 Jun 2009, Nikunj R. Mehta wrote: Would it be possible to edit the Web Storage API draft to include the proposed [1] programmable HTTP cache [2] in it? I don't think it needs to be in the Web Storage specification; it seems like it would be better to have it in its own specification. That way it can progress faster along the standards track. The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. I suppose the precedent is commit-then-review. Is that practice relevant in this case? What software and configuration do I need to commit? I believe the working group's team contact can provide you with CVS access if you want to commit a draft to dev.w3.org. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
dev.w3.org CVS access [was: Why I don't attend the weekly teleconference]
Ian Hickson i...@hixie.ch, 2009-06-24 00:10 +: I believe the working group's team contact can provide you with CVS access if you want to commit a draft to dev.w3.org. Yes, we can set up dev.w3.org CVS access for any member of the working group who wants to have it. The authentication is SSH2-based, so what we would need from you is an SSH2 public key (either RSA or DSA, doesn't matter). --Mike -- Michael(tm) Smith http://people.w3.org/mike/
