[webidl] DOMString
If something takes a DOMString as value is it clearly defined what happens
if the toString algorithm throws or returns a non-DOMString? I haven't
been able to find descriptions for that in the Web IDL specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [webidl] DOMString
On Apr 21, 2009, at 1:38 AM, Anne van Kesteren wrote:
If something takes a DOMString as value is it clearly defined what
happens if the toString algorithm throws or returns a non-DOMString?
I haven't been able to find descriptions for that in the Web IDL
specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
The [[ToString]] algorithm is defined in ECMAScript (Section 9.8,
[1]), the specified behaviour would result in [[ToString]] on obj2
producing the string 1; [[ToString]] on obj3 will result in a
TypeError, as [[DefaultValue]] will produce a non-primitive type
(Section 9.1, [1])
I would assume that the exception will be propagated to the runtime,
but it should be stated.
--Oliver
[1] ECMA262-5 RC
http://www.ecma-international.org/publications/files/drafts/tc39-2009-025.pdf
--
Anne van Kesteren
http://annevankesteren.nl/
RE: [widgets] Screenshots and case sensitive file names
Dear Marcos, See my comments inline. Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Montag, 20. April 2009 15:22 To: Hillebrand, Rainer Cc: public-webapps Subject: Re: [widgets] Screenshots and case sensitive file names Hi Rainer, On Mon, Mar 16, 2009 at 3:11 PM, Hillebrand, Rainer rainer.hillebr...@t-mobile.net wrote: Dear Marcos, The current version W3C Working Draft 11 March 2009 does not mention the gallery in Chapter 6.9: A screenshot is an optional file inside the widget resource that graphically represents the widget in a running state. Well, the question is what is a running state and which kind of application uses the screenshot. As it is written in the draft spec it could also be used by the WUA to graphically represent a widget. I would assume that it is out of scope for the PC to define which application uses a screenshot for which purpose. As we discarded screenshots, I guess that addresses the confusion. Ok! By the way, the current CSS settings move the text to the left so that I cannot see the whole text after Chapter 7.7 in an IE 6.0. I can only suggest using a modern browser that supports Web standards... have you tried Opera?;) I do not have a choice in T-Mobile but your page uses valid CSS code. I privately use Opera and Opera Mobile besides other browsers for testing my web pages and widgets. ;-) Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Proposal for ISSUE-83
ISSUE-83 states: Instantiated widget should not be able to read digital signature http://www.w3.org/2008/webapps/track/issues/83 The following is a proposal of text to add to PC to address this issue, based on text from Marcos and adding the notion of allowing policy and access control mechanisms to be used: Where a user agent that implements this specification interacts with implementations of other specifications, this user agent MUST deny other implementations access to digital signature documents unless an access control mechanism is in place to enable access according to policy. The definition of such a policy mechanism is out of scope of this specification, but may be defined to allow access to all or parts of the signature documents, or deny any such access. An exception is if a user agent that implements this specification also implements the OPTIONAL [Widgts-DigSig] specification, in which case the user agent MUST make signature documents available to the implementation of the [Widgets-DigSig] specification. This message should complete ACTION-329 which should be closed. regards, Frederick Frederick Hirsch Nokia
Re: Proposal for ISSUE-83
On Tue, Apr 21, 2009 at 3:31 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: ISSUE-83 states: Instantiated widget should not be able to read digital signature http://www.w3.org/2008/webapps/track/issues/83 The following is a proposal of text to add to PC to address this issue, based on text from Marcos and adding the notion of allowing policy and access control mechanisms to be used: Where a user agent that implements this specification interacts with implementations of other specifications, this user agent MUST deny other implementations access to digital signature documents unless an access control mechanism is in place to enable access according to policy. The definition of such a policy mechanism is out of scope of this specification, but may be defined to allow access to all or parts of the signature documents, or deny any such access. An exception is if a user agent that implements this specification also implements the OPTIONAL [Widgts-DigSig] specification, in which case the user agent MUST make signature documents available to the implementation of the [Widgets-DigSig] specification. Added under Digital Signatures section. If Mark is happy, then we should close this issue. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widgets 1.0 Packaging and Configuration: I18N comments...
On Thu, Apr 16, 2009 at 12:30 PM, jere.kapy...@nokia.com wrote: Marcos, thanks for a lucid and thorough widget I18N model proposal. This should really help all concerned to come to agreement about how widgets should be internationalized and localized. Also in this case I18N turned out to be more than many perhaps thought it would, but the effort is worth it, given the importance of being able to present widgets in the user’s language. I’ve taken a first look at the proposal document (rev1.19 as of April 15); please accept a few comments. Wrt PROPOSAL A2, I would strongly recommend that the single language tag be non-empty. There is always some default language that can be retrieved or derived. Allowing an empty language tag serves no purpose, and really just complicates matters. I'm worried about absolute edge cases where the system lang cannot be derived for whatever reason. In which case, I think i does no harm to leave it as an empty string. For all intents and purposes, that is equivalent to just saying use unlocalized content. Wrt PROPOSAL A1, the same thing applies. The language tag list should be non-empty. Although I’m not convinced that multiple language tags are of value. As examples, both Opera and Mac OS allow language lists (and I understand those lists are used during localization). In this context, it should also be noted that the same widget probably shouldn’t use content labeled with two or more completely disjoint language tags. So we are clear, do you mean, for example, en,zh? At least the language must be a common denominator, even if subtags differ. I asked internally and our localizers said that it was ok most of the time to allow subtags to differ. Localizers don't always have content (e.g., software might be released with an english license because it would be too expensive to hire a lawyer to translate the license to a different language). So there should never be a case where the user’s preferred language list is used naively when locating resources that are not found. (Example from A1 shows “en-us,en,fr,*” -- in this case if you want resource X but it is not found for ‘en-us’ or ‘en’, then you shouldn’t go looking for an ‘fr’ version of it.) This adds another layer of intelligence. I think we should just go with the list and end-user beware. Otherwise, we should go with A2 (one UA locale only). In “The widget’s locale”, the first question strikes me as odd. I'm going to assume you are talking about From which localized content should the widget's locale be derived, and in what order? The localizable materials in the configuration document and in the folders seem like disjoint enough that there is no issue of mixing those two. The widget’s locale is the same for both, as it is determined from the UA locale. Yes, this is probably true in most instances. Though I can think of lots of applications where this would not be true. For example, you could have an artistic musical instrument widget, whose only localization happens in the configuration document (e.g, it's name, description). But none of the files are be localized. So, if you derive the locale from the folder first, then the UA is in trouble... argh, this was a mistake on my part then, C3, as you suggest below, is the right option probably. If there are no entries for the widget’s locale in the config file, or if there is no relevant folder content, then a fallback/default is used. Right! This needs to happen on both counts. The second question should be simple enough: The second question being should the widget's locale be represented as a single language tag or as multiple language tags? the widget’s locale should be represented as a single language tag, based on the UA locale. If there are indeed multiple preferred languages, in the order of preference, then it is the first one. But this is based on matching to element based and folder based content (ALA C3). So, taking C3, you have at a minimum 2 locales, which may differ and the unlocalized content. I think that is a good option. IMHO there shouldn’t be any overlap between folder content and config document. Agree. It was dumb of me to think otherwise. They serve different purposes: the config document has mostly housekeeping data, whereas folder content is presented to the user dynamically at runtime. This is why I don’t like PROPOSAL B3. The locale for both config elements and folders must be the same. Soryr, I'm confused. You say element-based and content-based data serve different purposes, but then you say they need to be the same locale? why? I think it's ok, for instance, to have the license in English (element-based) and the UI (folder-based) in Spanish. Of course, it would be better to have everything in one lang, but that might not be possible. My preference is clearly to have one well-defined, non-empty language tag represent the widget’s locale. If there are no config elements or
Re: [widget] [widget-digsig] Comment on WD of Widgets 1.0: Digital Signatures - use of Created property
if there is no need for the Created property in the Widgets Signature spec I suggest we remove it, though keep what we have in the Signature Properties specification. regards, Frederick Frederick Hirsch Nokia On Apr 15, 2009, at 5:45 AM, ext Priestley, Mark, VF-Group wrote: Dear All, I have a number of comments against the Created property. As previously communicated on conference calls (although I can't find the relevant minutes) Vodafone objects to the mandatory use of the Created property. The main objection is that on mobile devices the user often does not set the correct time (or more usually the correct year) which means the device defaults to the time/year of manufacture. As a result many signatures will contain Created property values that, as far as the device is concerned, happen in the future. Without a requirement on a reliable and accurate timesource, which we are not proposing to introduce, the Created property cannot be relied on. This combined with the fact that the use of the Created property is down to the signer, or the signing scheme within which the signer is operating, mean we think its use should be optional. This general comment translates to the specific comments below. - 5.1 Each signature file MUST contain a dsp:Created signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification. We would like to see the above changed to a MAY. - 5.6 As an example of use, assume a distributor's signing process is found to have been compromised. Thus, it is not practical to exchange the signature key. Being able to invalidate all signatures made before a particular date would be important in such a scenario. I'm not sure the above is a good example? If the signing process has been compromised then I may want to invalidate signatures before this date, but wouldn't I also change my key at this time to stop creating new compromised signatures? In this case the end-entity cert should be revoked. My understanding of timestamps was that their main reason for being is to confirm that a signature was created at a particular instance in time. This information can then be used for non-repudiation and/or proof of existence of the signed object at a particular time in the past. The above use case seems to be suggesting something else which I do not fully understand. As previously communicated I think there is a case for an Expires property, which could be used to state a point in time after which a Signature is no longer valid (to allow for Signature with shorter lives than the keys used to create them), but this is different from the Created property. My suggestion is to rework the example. - 7.2 The sentence: A wall clock timestamp SHOULD be placed is inconsistent with the text in 5.1 which states the element as a MUST. If the text in 5.1 is changed to a MAY then the text in 7.2 would be OK but we would prefer to make this a MAY as well. - 7.3 The Created Signature Property value SHOULD represent a wall clock timestamp earlier than the current time, to the nearest minute. It's not clear what the user agent should do to respect this requirement? We think that this should be left to the signer or signing scheme to reflect use of the Created property through the UA's security policy. The text on the Created property could then be deleted from this section. - 9.2.1 Upon signature generation, if this property is used, the time value is set to a reference time, as defined by the application. Again, this is inconsistent with the text in 5.1 in which the Created property is mandatory, unless the intention of the text is to be if the property is used by the UA? - 9.2.2 We think it should be made clear that Validation of the Created property is optional. Thanks, Mark Mark Priestley Mobile: +44 (0)7717512838 E-mail: mark.priest...@vodafone.com Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001
Re: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10
Hmm.. I tend to agree. Using an SQL database is only one possible solution that we should be examining. I would rather say that we should provide storage for structured data inside the UA. I'm not a fan of calling out neither SQL or name-value pair storage. At the same time I'm not sure that I care that much about it, as long as we can change the draft later in case the spec takes a different turn than the current drafts. / Jonas On Tue, Apr 21, 2009 at 2:44 PM, Nikunj Mehta nikunj.me...@oracle.com wrote: Apparently the new charter [1] that forces everyone to re-join the WG also lists among its deliverables as WebStorage with the explanation that WebStorage is two APIs for client-side data storage in Web applications: a name-value pair system, and a database system with a SQL frontend Clearly, if the WD of WebStorage has in its abstract something more general, the charter should not be so specific. I now understand that this new piece of text made its way into the charter recently. The last message I can see about charter change for WebApps [1] only talks about adding WebWorkers. Apparently other changes were also made, but no diff provided to members about the charter change proposal. Can you throw some light on this? Nikunj [1] http://www.w3.org/2009/04/webapps-charter [2] http://www.w3.org/mid/3e428ec7-1960-4ece-b403-827ba47fe...@nokia.comian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. Done.
Re: [webidl] DOMString
Anne van Kesteren: If something takes a DOMString as value is it clearly defined what happens if the toString algorithm throws or returns a non-DOMString? Oliver Hunt: I would assume that the exception will be propagated to the runtime, but it should be stated. Seems reasonable to state that. I’ve added a note to do that when I get some time to allocate to editing Web IDL again. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
On Apr 21, 2009, at 6:08 PM, Cameron McCormack wrote: Anne van Kesteren: If something takes a DOMString as value is it clearly defined what happens if the toString algorithm throws or returns a non-DOMString? Oliver Hunt: I would assume that the exception will be propagated to the runtime, but it should be stated. Seems reasonable to state that. I’ve added a note to do that when I get some time to allocate to editing Web IDL again. I actually thought about this some more, and realised i'm not entirely sure this should be part of webidl as it seems a little too language specific. Eg. WebKit also provides an objective-c interface to the DOM to application developers, allowing them to interact with a webpage (or other content) through the DOM directly from their application code. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
It’s only the ECMAScript language binding that uses the ES ToString etc. algorithms, so I think it would be fine to define in the ES language binding section that exceptions thrown when converting an IDL value to an ECMAScript value or vice versa will propagate to whatever invoked that conversion. Oh of course, completely forgot that there's actually a set of bindings sections :D Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Effectively this is what WebKit does to generate it's ES and Obj-C bindings. -- Cameron McCormack ≝ http://mcc.id.au/
Re: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10
Hi, Nikunj- Nikunj Mehta wrote (on 4/21/09 5:44 PM): Apparently the new charter [1] that forces everyone to re-join the WG also lists among its deliverables as WebStorage with the explanation that WebStorage is two APIs for client-side data storage in Web applications: a name-value pair system, and a database system with a SQL frontend Clearly, if the WD of WebStorage has in its abstract something more general, the charter should not be so specific. Yes, I can see where you're coming from. I now understand that this new piece of text made its way into the charter recently. Yes, in the final round of revisions after the AC review, we clarified some of the deliverables, and I pulled the descriptions from each spec. The last message I can see about charter change for WebApps [1] only talks about adding WebWorkers. Apparently other changes were also made, but no diff provided to members about the charter change proposal. Here is the original charter: http://www.w3.org/2008/webapps/charter/charter2008.html And here is the new charter: http://www.w3.org/2009/04/webapps-charter In the original charter, what is now called Web Storage did not yet have a formal name, but was called out: [[ Offline APIs and Structured Storage for enabling local access to Web application resources when not connected to a network ]] So, it was already in the charter, but only named recently when the WebApps WG agreed to publish the spec (after the first draft of new charter was written). Can you throw some light on this? Ian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. Done. Your request to change this (and Ian's subsequent change) came after the charter was in its final form that was approved by W3M (as you can see by the timestamp at the bottom of the final version) [1]. So. it's really a matter of unfortunate timing. Normally, such changes to the charter after the fact are frowned upon, but under the circumstances, I will see if it is acceptable to amend this, since the WebApps WG seems to agree that more general wording is preferred. Sorry for the confusion. [1] http://www.w3.org/2009/04/webapps-charter Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
