RE: [WebIDL] grammar in ABNF
Ah I see the confusion is more about how strongly the ‘|’ operator binds compared to adjacent symbols. Yes. I am more used to ABNF, thus my request. Thanks for your follow-up. 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: Cameron McCormack [mailto:c...@mcc.id.au] Sent: Wednesday, July 01, 2009 7:39 AM To: Marcin Hanclik; public-webapps Subject: Re: [WebIDL] grammar in ABNF Marcin Hanclik: I had the following problem: [45]ScopedName - :: ScopedNameAfterColon | identifier ScopedNameParts Where I assumed that each ScopedName has to start with ::, because according to ABNF this production has to be written as [45ABNF]ScopedName = (:: ScopedNameAfterColon) | (identifier ScopedNameParts) Cameron McCormack: Was the confusion because the ‘:: ScopedNameAfterColon’ and ‘identifier ScopedNameParts’ weren’t written on the same line? Ah I see the confusion is more about how strongly the ‘|’ operator binds compared to adjacent symbols. -- Cameron McCormack ≝ http://mcc.id.au/ 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: [WebStorage] Property enumeration and checking presence
Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-30 14:54 -0700: On Jun 30, 2009, at 10:28 AM, Michael(tm) Smith wrote: Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-30 09:12 -0700: I was inquiring about the term property enumeration I think in this case it means iterating over the Storage object to get a list of all its properties. Similarly, I also wanted to know the meaning of checking the presence of a property. I think in Javascript terms at least, it means using the in operator to check if the Storage object has a particular property. Is the spec complete in regards to this and does it need to clarify what is meant by these two conditions? If it is unclear to you, I'd say it's likely to be unclear to some others. So I think it might be worth taking time to suggest that the editor consider how to clarify it -- which you can do either be posting a message to this list, or by raising it as an issue in the W3C bugzilla for the group: http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG I would imagine that these are special ECMAScript cases, am I right? Yeah, it does seem to me at least that as currently worded at least, they're specific to ECMA/Javascript. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
What about [ESNativeObject]?
Regarding the whole use case (PositionOptions and its usage in Geo spec,
similar use cases in many BONDI modules) that ignited this mail thread, in
BONDI we consider the proposal of [Enumerable] extended attribute for
interfaces (suggested off-line by Cameron) and [Optional] for attributes. In
short we talk about the case that would resemble passing arguments by value,
that would allow incomplete specification of the object properties - both as
input/argument/value and as output/object and that is about property
enumeration (i.e. about removal of {DontEnum} that is a standard now for Web
IDL interface properties).
There will be another email about that posted soon.
BTW:
Property enumeration seems to be a topic also in this mail thread:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1371.html
Thanks.
Kind regards,
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: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Wednesday, July 01, 2009 6:11 AM
To: Cameron McCormack
Cc: Giovanni Campagna; Kruessel, Steffen; Marcin Hanclik; WebApps WG;
i...@hixie.ch
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
On Jun 30, 2009, at 8:12 PM, Cameron McCormack wrote:
Hi Steffen, Giovanni.
Giovanni Campagna:
[Callback], despite the names, does not mean that the interface will
be called back by a method accepting it (although that was the
initial
use case). It barely means that you can convert an Object (in the
ECMAScript sense) to an object in the WebIDL sense, of that
interface.
I agree with everything Giovanni said.
Regarding the name of the extended attribute: it used to be called
[NativeObject], but there were restrictions on it so that it could
only
be used on interfaces with operations (and not attributes). Ian then
requested it be renamed to [Callback], since that was more
descriptive.
Since that restriction has now been lifted, and [Callback] interfaces
can have attributes, I agree that [Callback] isn't the most obvious
name
any more.
Anybody object to renaming it back to [NativeObject] then (or can
suggest a better name)?
The name NativeObject seems nondescriptive and could easily be taken
as the opposite of what it means. For example, in the browser context,
code written in C++ is often called native but code written in
JavaScript typically is not. But NativeObject would be applied to
interfaces that are expected to be implemented in JavaScript, perhaps
even just by specifying a function directly.
I'm not sure if there is a better word than Callback to connote an
interface that is expected to be implemented by clients of the API
rather than implementation of the API. Maybe ClientInterface or
ClientObject.
Regards,
Maciej
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: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
On Jun 30, 2009, at 11:29 PM, Marcin Hanclik wrote: What about [ESNativeObject]? I don't think the property should be ES-specific. It would probably have effects for other language bindings too. I'm also not sure this clarifies the use of Native. Regards, Maciej
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
If the extended attribute should not be ECMAScript, the description at http://dev.w3.org/2006/webapi/WebIDL/#Callback must also be revised due to the strong ES-reference. What about [ValueTypeInterface]? Regards, Steffen -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Wednesday, July 01, 2009 9:15 AM To: Marcin Hanclik Cc: Cameron McCormack; Giovanni Campagna; Kruessel, Steffen; WebApps WG; i...@hixie.ch Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject On Jun 30, 2009, at 11:29 PM, Marcin Hanclik wrote: What about [ESNativeObject]? I don't think the property should be ES-specific. It would probably have effects for other language bindings too. I'm also not sure this clarifies the use of Native. Regards, Maciej
Re: http://dev.w3.org/2006/waf/widgets/#reserved-file-and-folder-names
On 6/30/09 7:49 PM, timeless wrote: On Tue, Jun 30, 2009 at 4:24 PM, Marcos Caceresmarc...@opera.com wrote: Or use index.html in other directories? Nothing. Treated as an arbitrary file - this was already implied in the spec. To make this explicitly clear, I've added: speaking of which, doesa href=foo/foo/a magically map to a file? i'm assuming we're going to wait until the widget uri scheme suggests a handling for that. Yes, I think so.
Re: [widgets] Rule for dealing with an invalid Zip archive
On Wed, Jun 10, 2009 at 4:51 PM, Anne van Kesterenann...@opera.com wrote: There's no need to recommend something twice so everything after the last semicolon can be dropped. Editorial: Agreed, dropped. The usage of inform here assumes the user agent in question is a conformance checker. However, it is far more likely that this is a normal user agent that can run widgets. As such, the usage of inform here is inappropriate for that class of products. Editorial: Good point. I changed it to: [[ In the event that an implementation encounters an invalid Zip archive during the steps for processing a widget package, the user agent must abort all processing of the steps for processing a widget package. In addition, the user agent should notify the end-user that the zip archive is an invalid Zip archive via an appropriate localized error message. The means of notifying the end-user, and the wording of the localized error message, is left to the discretion of implementers. In the case the UA is a CC, it must inform the author that the Zip archive is an invalid Zip archive. ]] Is that any better? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Rule for getting a single attribute value
On Wed, Jun 10, 2009 at 5:00 PM, Anne van Kesterenann...@opera.com wrote: Why does this not reuse the general definition of space characters? Same comment applies to Rule for getting a list of keywords from an attribute it seems. Fixed, both rules now read: In result, replace any sequences of space characters (in any order) with a single U+0020 SPACE character. Functionally, I don't believe this change either algorithm, so this will be treated as an editorial comment. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [cors] Additional Comments on 17 March 2009 cors draft
I might not have time to address your larger set of questions before I leave on vacation tomorrow, but I thought I could at least answer this one. On Tue, 30 Jun 2009 17:38:20 +0200, Frederick Hirsch frederick.hir...@nokia.com wrote: One additional question regarding a cross-site get (using browser here for simplicity of terms) (for example, see [1]) Is it true that 1. the GET results in the content being returned on the wire with a Access-Control-Allow-Origin header 2. the browser then checks this header and enforces policy 3. if policy disallows then the browser does not allow the content to be used. Yes, this is correct. In any case, doesn't this open an attack to get the content by sniffing the wire for the response content, regardless of the header? If that is a viable attack scenario such servers are already exposed due to e.g. cross-origin img or iframe loading which already works today. Or e.g. by simply setting window.location to the address from which you want to sniff the response. All the header is effectively protecting is exposing the raw contents of a cross-origin resource to script. [1] http://arunranga.com/examples/access-control/SimpleXSInvocation.txt -- Anne van Kesteren http://annevankesteren.nl/
Re: File API Feedback
On Wed, Jul 1, 2009 at 2:22 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: The picasa-style example mentioned earlier uses the word upload. I've not used Picasa, but it appears to read files off a local network. confused. i suspect i was the one who mentioned it. Picasa is mostly a local application. One can do a large number of operations with it. among them: 1. select a number of local files 2. get previews (in some file formats that might be possible by sampling, e.g. an interlaced image format) 3. rotate 4. color correct (etc.) 5. upload in the case of getting previews and doing manipulations (which are actually done in two passes, a fast pass on the preview, and then an expensive background pass on the underlying data), these are local operations where portions of a file would be sufficient in certain stages. And it definitely would make sense to be able to upload a large file in chunks. I'm glad to see the API under discussion is growing support for ranges. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/
Re: [widgets] Rule for Getting Text Content
2009/6/10 Anne van Kesteren ann...@opera.com: I don't really like the optional ITS behavior. Also, what is the effect of having it there? My understanding is that, in implementations, the appropriate unicode directionality markers would be inserted where the its elements and attributes appear. If this is a feature needed by authors it also seems better for them if they have it without all the additional namespaces. This is here because I18N community requested it, we added it, it's optional and has been marked as a feature-at-risk (as described and allowed in the process document). If no one implements it, then we will remove it. textContent is an attribute, not a property. In bindings it might turn into a property, but that is not relevant I think. Fixed. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Rule for Identifying the Media Type of an Image
2009/6/10 Anne van Kesteren ann...@opera.com: For SVG none, see comment. does not help as the comment does not clarify what is supposed to happen. Agreed. I think the correct answer here is that SVG only works if you use the proper extension and it would be worthy to point that out crystal clear. The comment now reads: SVG documents cannot be identified using a magic number, as they don't have one; SVG must only matched by the .svg file extension and processed in accordance to the [SVGTiny] specification. Would you say that is crystal clear or close enough? Also, following the definition of file-extension _none_ of the entries in the table would be matched. I.e. file-extension requires a leading dot. Fixed. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Rule for Determining if a potential Zip archive is a Zip archive
2009/6/10 Anne van Kesteren ann...@opera.com: I think the first paragraph here can be dropped as you cannot test it. Optionally you could rephrase it as a non-normative note. Changed this to a note. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] PC comments, 8
On Mon, Jun 29, 2009 at 2:10 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, All, These are a few editorial comments to the latest PC ED. 6.6 Icons and 9.1/Step7/icon Step7 requires only a valid path for src attribute: Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list. whereas 6.6 is more restrictive and says: An icon must be located either at the root of the widget package or at the root of a locale folder. I've removed (as part of Kai's comments, who noted the same issue): An icon must be located either at the root of the widget package or at the root of a locale folder. I've redefined the definitions: A custom icon can be located either at the root of the widget package, or at the root of a locale folder, or in an arbitrary folder. A default icon must be located either at the root of the widget package or at the root of a locale folder. Therefore I suggest to refer to 6.6 from Step7 is some way, e.g. by creating a new rule for icon path or by just adding some prose in Step7, like: Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path or does not fulfill the restriction from 6.6, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list. 6.6.1 basically now says that an custom icon can appear anywhere, so I think what is there is now fine. 7.12 Note A user agent can expose a feature through, for example, an API, in which case a user agent that supports the [Widgets-APIs] specification can allow authors to check if a feature loaded via the hasFeature() method. (Non-normative) [Widgets-APIs] spec says nothing about loading features, at least now. True. I removed the note but reused some of the text in the actual element definition: A feature is a runtime component (e.g. an Application Programming Interface or video decoder) that is not part of the specified set provided by the Widgets 1.0 family of specifications. The feature element serves as a standardized means to request the binding of an (URI) identifiable runtime component to a widget for use at runtime. Using a feature element denotes that, at runtime, a widget may attempt to access the feature identified by the feature element's name attribute. How a user agent makes use of features depends on the user agent's security policy, hence activation and authorization requirements for features are beyond the scope of this specification. It seems not to be agreed that hasFeature() method would be used for that purpose, specifically because hasFeature() is used in DOM to check for - static IMHO - existence of some module/functionality/feature, and feature loading that is meant within PC is of dynamic nature. hasFeature was dropped at the F2F. So I suggest removing that sentence from the note in order not to create a de-facto standard. Agreed. What do you think of the text above? -- Marcos Caceres http://datadriven.com.au
Simple Web Storage
Hello,
Long time fan, first time writer. ;)
I've been following the Web Storage proposals with interest, and was
just independently drafting a mail suggesting the a B-Tree API would
be much simpler to standardize, and would be an adequate foundation
for building most anything more specific.
I'd like to express my support for a BDB style API. Firstly because it
would be much less prone to vendor differences, and secondly because I
can see how to implement a performant CouchDB on top of it. It could
be a bit harder to build a SQL-like interface on raw B-Trees, but
completely possible if someone is determined.
I don't think we need to worry about specific vendor implementations,
just a unified API with very small surface area. To build CouchDB all
we'd need is B-Trees that support in-order and reverse-order
traversal, and optionally user-defined collation functions.
Here's a first cut at imagining the API:
=== JS pseudocode ===
var btree = new WebStore(dbname, optional collation function definition);
btree[mydocid] = {some:json};
btree.forEach(function(key, value) {
// in order traversal
})
btree.forEach(function(key, value) {
// reverse order traversal
}, false)
btree.forEach(startkey, function(key, value) {
// in order traversal, starting from startkey
// we could use throw() to stop traversal
})
btree.forEach(endkey, function(key, value) {
// reverse order traversal, starting from endkey
// use throw() to stop traversal
}, false)
// delete a btree
WebStore.drop(dbname);
===
Thoughts?
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
[widgets] PC comments, 9
Hi Marcos, I have found other typos: Step 7, icon; Let file the result of applying Should be Let file be the result of applying 6.6.2 A default icon is an reserved icon ... Should be A default icon is a reserved icon ... A default icon must be located either at the root of the widget package or at the root of a locale folder. is repeated twice. Thanks. Kind regards, 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 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: [widgets] PC comments, 8
Regarding 6.6 Step7: Thanks. Ok. Regarding 7.12 Agreed. What do you think of the text above? Thanks, I am ok with the text. 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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, July 01, 2009 1:23 PM To: Marcin Hanclik Cc: public-webapps WG Subject: Re: [widgets] PC comments, 8 On Mon, Jun 29, 2009 at 2:10 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, All, These are a few editorial comments to the latest PC ED. 6.6 Icons and 9.1/Step7/icon Step7 requires only a valid path for src attribute: Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list. whereas 6.6 is more restrictive and says: An icon must be located either at the root of the widget package or at the root of a locale folder. I've removed (as part of Kai's comments, who noted the same issue): An icon must be located either at the root of the widget package or at the root of a locale folder. I've redefined the definitions: A custom icon can be located either at the root of the widget package, or at the root of a locale folder, or in an arbitrary folder. A default icon must be located either at the root of the widget package or at the root of a locale folder. Therefore I suggest to refer to 6.6 from Step7 is some way, e.g. by creating a new rule for icon path or by just adding some prose in Step7, like: Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path or does not fulfill the restriction from 6.6, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list. 6.6.1 basically now says that an custom icon can appear anywhere, so I think what is there is now fine. 7.12 Note A user agent can expose a feature through, for example, an API, in which case a user agent that supports the [Widgets-APIs] specification can allow authors to check if a feature loaded via the hasFeature() method. (Non-normative) [Widgets-APIs] spec says nothing about loading features, at least now. True. I removed the note but reused some of the text in the actual element definition: A feature is a runtime component (e.g. an Application Programming Interface or video decoder) that is not part of the specified set provided by the Widgets 1.0 family of specifications. The feature element serves as a standardized means to request the binding of an (URI) identifiable runtime component to a widget for use at runtime. Using a feature element denotes that, at runtime, a widget may attempt to access the feature identified by the feature element's name attribute. How a user agent makes use of features depends on the user agent's security policy, hence activation and authorization requirements for features are beyond the scope of this specification. It seems not to be agreed that hasFeature() method would be used for that purpose, specifically because hasFeature() is used in DOM to check for - static IMHO - existence of some module/functionality/feature, and feature loading that is meant within PC is of dynamic nature. hasFeature was dropped at the F2F. So I suggest removing that sentence from the note in order not to create a de-facto standard. Agreed. What do you think of the text above? -- Marcos Caceres http://datadriven.com.au 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.
XMLSerializer should run HTML serialization algorithm when input doc is HTML
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=500937 The proposed patch there and (based on black-box testing) WebKit solve the issue by running the HTML serialization algorithm when the owner document of the input node is an HTML document. This should probably be in a spec somewhere. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [widgets] Comments on Widgets 1.0: Packaging and configuration, 9.1 Processing rules
Hi Francois, On Sun, Jun 14, 2009 at 7:47 PM, Francois Daoustf...@w3.org wrote: Hi, Oops, it looks like I have a few more points to make on path resolution. These comments apply to the editor's draft 11 June 2009 version of the Widgets 1.0: Packaging and Configuration specification. Comments apply to the Rule for finding a file within a widget package section in 9.1 Processing rules: http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget- Comment 1 is minor. Comment 2 is more important in my view. Comment 3 is not a big deal, although I think the spec introduces complexity where it's not needed. Comment 1: relative can't be absolute - Step 3: meaning that the path is an Zip absolute path How can path be a Zip absolute path? It is defined in step 1 as the Zip relative path to the file entry being sought. A zip relative path cannot start with a /. Updating to definition of path to the valid path to the file entry being sought should solve the problem (valid path = zip-rel-path | zip-abs-path) Fixed. Used your text. Comment 2: links resolution in e.g. start file - The specification implies but does not define how links in documents other than the configuration document are to be handled (or did I miss something?). In particular, how is a user agent supposed to resolve relative links to packaged files that appear in the start file? You are absolutely right. However, the WG decided that URI resolution is out of scope for the PC specification so we only recently published Widgets 1.0: URI Scheme specification: http://dev.w3.org/2006/waf/widgets-uri/ To make sure that it is clear that the PC spec will not be handling URIs outside the scope of the config.xml, I've added the following note to the spec: Note: This specification does not define how links in documents other than the configuration document are to be dereferenced. For handling links in other documents, such as (X)HTML, CSS, SVG, ect., please refer to the [Widgets URI] specification. Is the above text sufficient? If the rule for finding a file within a widget package is to be followed, the behavior is going to be strange in some cases. Consider the case of a configuration document whose start file is defined as: /startfolder/index.html If index.html then uses relative paths to include an image, e.g. bar.gif, I would expect the user agent to behave as a regular Web browser, and resolve bar.gif in the same folder as index.html, i.e. /startfolder/bar.gif. Leaving localization aside for a second, step 5 of the rule for finding a file within a widget package will be reached, and that means bar.gif will actually be searched at the *root* of the widget package, and not in /startfolder. That's weird. As above, this will be handled by a different spec. I think you should explain how to construct the Zip valid path of a file entry from a relative path that may appear in a document and the path of the document in question, i.e. from bar.gif to /startfolder/index.html in the previous example. I agree, but this will all be handled by the widgets URI specification. Comment 3: localization and absolute URIs - We more or less already exchanged emails on that, but... I don't understand the need to have absolute paths bypass localization. I guess the logic is that authors, for whatever reason (e.g., force testing a locale without needing to change the locale on their device), are going to use absolute URIs, so I'm of the opinion that we support them. Consider the two examples below: 1. a config document that contains a content src=startfolder/index.html / directive 2. a config document that contains a content src=/startfolder/index.html / directive I think people are used to using relative and absolute paths in links interchangeably. Since the config document is at the root of the widget, I would expect the two examples to have the same effect. Yes, they would have the same effect iff the folder structure was: widget.wgt /startfolder/ But, for whatever reason, the folder structure was as follows, it would also work: widget.wgt startfolder/index.html fr/startfolder/index.html jp/startfolder/index.html Here, if the widget's package contains a locales/fr/index.html, it may be used in the first case (provided fr is in user agent locales of course), but it won't ever be used in the second case. Yes, for case 1, so long as: widget.wgt fr/startfolder/index.html And yes, it will not be matched in case 2... which is what I would expect. I realize that when an absolute path is treated the same way as a relative path, the Complex example of 8.4 Localization Examples: http://dev.w3.org/2006/waf/widgets/#complex-example ... cannot be implemented as such in practice. I think that's fine, there should not be any way for something in a locales/[LANG] folder (or wherever else for that matter) to bypass the localization algorithm. Having one
Re: [widgets] PC comments, 9
On Wed, Jul 1, 2009 at 2:04 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, I have found other typos: Step 7, icon; Let file the result of applying Should be Let file be the result of applying Fixed. 6.6.2 A default icon is an reserved icon ... Should be A default icon is a reserved icon ... Fixed. A default icon must be located either at the root of the widget package or at the root of a locale folder. is repeated twice. Fixed Thanks. Kind regards, 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 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. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] PC comments, 9
DoC: Thanks for all fixes. 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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, July 01, 2009 2:21 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [widgets] PC comments, 9 On Wed, Jul 1, 2009 at 2:04 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, I have found other typos: Step 7, icon; Let file the result of applying Should be Let file be the result of applying Fixed. 6.6.2 A default icon is an reserved icon ... Should be A default icon is a reserved icon ... Fixed. A default icon must be located either at the root of the widget package or at the root of a locale folder. is repeated twice. Fixed Thanks. Kind regards, 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 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. -- Marcos Caceres http://datadriven.com.au 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: [cors] Additional Comments on 17 March 2009 cors draft
So the issue is not confidentiality, it is inappropriate script execution. Got it. Thanks Anne regards, Frederick Frederick Hirsch Nokia On Jul 1, 2009, at 5:34 AM, ext Anne van Kesteren wrote: I might not have time to address your larger set of questions before I leave on vacation tomorrow, but I thought I could at least answer this one. On Tue, 30 Jun 2009 17:38:20 +0200, Frederick Hirsch frederick.hir...@nokia.com wrote: One additional question regarding a cross-site get (using browser here for simplicity of terms) (for example, see [1]) Is it true that 1. the GET results in the content being returned on the wire with a Access-Control-Allow-Origin header 2. the browser then checks this header and enforces policy 3. if policy disallows then the browser does not allow the content to be used. Yes, this is correct. In any case, doesn't this open an attack to get the content by sniffing the wire for the response content, regardless of the header? If that is a viable attack scenario such servers are already exposed due to e.g. cross-origin img or iframe loading which already works today. Or e.g. by simply setting window.location to the address from which you want to sniff the response. All the header is effectively protecting is exposing the raw contents of a cross-origin resource to script. [1] http://arunranga.com/examples/access-control/SimpleXSInvocation.txt -- Anne van Kesteren http://annevankesteren.nl/
[widgets] Draft Agenda for 2 July 2009 Voice Conference
Below is the Draft agenda for the July 2 Widgets Voice Conference (VC). Dom, Kai - if you are available for the Testing part of this call, please join us (you can track our progress in #wam). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it may result in a shortened meeting). Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes (maximum) 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 LC Comments http://dev.w3.org/2006/waf/widgets/ Comment Tracking doc: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20090528/ a. High priority comments; Marcos to supply list in advance of the meeting b. Issue raised by Francois http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 0037.html 4. Testing a. Widget Testing wiki http://www.w3.org/2008/webapps/wiki/WidgetTesting b. Dig Sig testing - call for inputs for testable assertion list c. Online Widget Checker service by Dom http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1201.html http://qa-dev.w3.org:8001/widget/ d. PC Test Plan by Dom http://dev.w3.org/cvsweb/2006/waf/widgets/tests/plan.html e. Testing update/status by Kai Hendry f. Test Fest proposal by David Rogers 5. Widgets AE spec: To Do list by Robin http://dev.w3.org/2006/waf/widgets-api/ http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1370.html 6. AOB
Re: An icon must be located either at the root of the widget package or at the root of a locale folder.
On Mon, Jun 19, 2009 at 4:40 PM, Kai Hendryhen...@iki.fi wrote: In your own configuration document example: icon src=icons/boo.png/ I.e. the icon is in the icons/ subdirectory. So that assertion needs a unless specified in an alternate location by a custom icon using the icon element appended or something simpler like that. Right. This was a bug in the spec. I've fixed it by explicitly stating where the two kinds of icons can reside: [[ A custom icon MUST be located either at the root of the widget package, or at the root of a locale folder, or in an arbritrary folder. ... A default icon MUST be located either at the root of the widget package or at the root of a locale folder. ]] A user agent must derive the media type of a default icon from the media type column of the default icons table. Why must a UA do it this way? Why can't it just sniff use the or just do it the way it thinks it should be done. Seems also inconsistent with rule for Identifying the media type of an image. How so? A user agent must search for a default icon's file-name based on the order they appear in the default icons table (from top to bottom). I thought you said it's upto the UA to choose the best icon? Yes, it's up to the UA, but you still need to search for them in the right order. Searching for icons and displaying them are different things. -- Marcos Caceres http://datadriven.com.au
Re: http://dev.w3.org/2006/waf/widgets/#default-start-file0
On Mon, Jun 19, 2009 at 4:31 PM, Kai Hendryhen...@iki.fi wrote: A default start file must appear at either the root of the widget package or at the root of a locale folder. unless a custom start file has been specified surely? http://dev.w3.org/2006/waf/widgets/#the-content-element Ok, fixed. Step 8 - Locate the Start File sez step only applies if a custom start file was not specified I think you just need to make these MUSTS consistent. Easy to see from: http://www.w3.org/2005/08/online_xslt/xslt?filter=mustxslfile=http%3A%2F%2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests%2FextractTestAssertions.xslxmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets%252F Yes, I need to go through all the output and fix it... it's a semi-big job. I'm going to go through the human feedback first then use the machine output to help me. If you want to save me some time, you could start listing all the places where further clarification is needed and feel free to recommend some text to add to make things better. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Denoting privacy-sensitive requests (was: Re: Do we need to rename the Origin header?)
Jonas Sicking wrote on 6/25/2009 5:35 PM: On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. Can you elaborate on the debate or point to an archive? HTML5 will have to enumerate the contexts in which requests are deemed privacy-sensitive (has this been added to HTML5 yet?), however, given that different sites will have different requirements, it may be likely that authors will want the ability to override the default behavior. - Bil
WebIDL extension proposal for [Enumerable] interface attribute
Hi there,
in a mail[1] earlier today, Marcin introduced some ideas we discussed
recently on the BONDI interfaces list. I noticed in the archives that
you had a related discussion about the geolocation PositionOptions and
also some conclusions like using the [Callback] attribute. As it has
been mentioned already, we identified various use cases of map-like
objects in the BONDI APIs, which are similiar to PositionOptions, but
not equal in all aspects.
We concluded that usually APIs will use two kinds of option objects,
value type interfaces and map-like interfaces. As a rule of thumb,
value type objects are often used as input arguments to APIs, whereas
map-like objects are mostly used as output arguments. A value type
interface can be easily specified already using WebIDL, however a
map-like interface has some constraints which can't be formally
specified atm.
- all attributes must be enumerable
- all attributes must be optional -- we'd like to formally specify
common attributes that are *usually* supported by API implementations
but must not
- the types of the specified attributes might differ from the actually
exposed values by a specific implementation due to the optionality of
the attributes
- the interface is extensible outside the spec scope -- an object that
implements such an interface can expose other/additional attributes
than the specified ones
For example, we are using a Map-like object that exposes file metadata
which differs among different files (eg an MP3 file has totally
different metadata than an executable), but the metadata might also
contain commonly used attributes like the file size or creation date.
Our current approach to this problem is to declare
typedef Object Map;
and using the Map type for these occasions with an informal
documentation of the actual Map attributes and their values. However,
we'd like to achieve a more formal way to do so.
That's why we propose the introduction of an extended interface
attribute called [Enumerable] into WebIDL and the introduction of the
extended attribute [Optional] for interface attributes. Given the
example of file metadata, such a map could be specified as follows:
[Enumerable] interface FileMetadata {
[Optional] attribute long size;
[Optional] attribute Date creation;
[Optional] attribute Date modification;
};
A generic Map-like interface that has no defined optional attributes
could look like:
[Enumerable] interface Map {};
What is your point of view?
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0019.html
Kind regards,
Anselm
Re: Widgets 1.0: Packaging and Configuration questions
On Wed, Jun 17, 2009 at 5:12 PM, Jeff Deckerw3c-upda...@celestialwake.com wrote: Hi Everyone, I was going over the PC spec and had a couple questions: 1. Under section 7.12 The feature Element it does not note how a widget user agent should handle an unknown feature name. Is this intended? Yes, this is intentional. Processing is actually defined in Step 7: x. If feature-name is not supported by the user agent, and required-feature is true, then treat this widget as an invalid widget package. x. If feature-name is not supported by the user agent, and required-feature is false, then this element, its attributes, and its children are in error and must be ignored. Stop processing this element and proceed to the next element in the elements list. I've added a note at the start of the Configuration Document section referring the reader to Step 7 for details about processing of elements. Hopefully that will alert the reader to where processing of elements is described. The note simply reads: Please see Step 7 for details of how the elements of the configuration document are processed by a user agent. Is that clear enough? 2. Under section 6.5 Start Files it says It is optional for user agents to support the media types listed in the default start files table. Does this mean a user agent can support any combination of Default Start Files from the table or are the files grouped under the media types? So If I were to support text/html, then I would need to search for both .htm and .html files? That is correct. Is that not clear enough? If no, can you suggest some text that would make that more clear? -- Marcos Caceres http://datadriven.com.au
Re: Simple Web Storage
On Wed, Jul 1, 2009 at 2:55 AM, Chris Anderson jch...@apache.org wrote:
Hello,
Long time fan, first time writer. ;)
I've been following the Web Storage proposals with interest, and was
just independently drafting a mail suggesting the a B-Tree API would
be much simpler to standardize, and would be an adequate foundation
for building most anything more specific.
I'd like to express my support for a BDB style API. Firstly because it
would be much less prone to vendor differences, and secondly because I
can see how to implement a performant CouchDB on top of it. It could
be a bit harder to build a SQL-like interface on raw B-Trees, but
completely possible if someone is determined.
I don't think we need to worry about specific vendor implementations,
just a unified API with very small surface area. To build CouchDB all
we'd need is B-Trees that support in-order and reverse-order
traversal, and optionally user-defined collation functions.
Here's a first cut at imagining the API:
=== JS pseudocode ===
var btree = new WebStore(dbname, optional collation function
definition);
btree[mydocid] = {some:json};
btree.forEach(function(key, value) {
// in order traversal
})
btree.forEach(function(key, value) {
// reverse order traversal
}, false)
btree.forEach(startkey, function(key, value) {
// in order traversal, starting from startkey
// we could use throw() to stop traversal
})
btree.forEach(endkey, function(key, value) {
// reverse order traversal, starting from endkey
// use throw() to stop traversal
}, false)
// delete a btree
WebStore.drop(dbname);
===
Thoughts?
The biggest thing I see missing is transactions.
Also, I don't know why web databases decided not to allow deletion or
enumeration of the database names, but I assume it was difficult or
impossible to do so in a non-racy way. It's definitely worth looking into
this before supporting some sort of drop. And if we did support it, it
seems as though the name could be more clear.
The rest seems reasonable.
I'm still concerned that this is not differentiated enough with
LocalStorage. The differences are: duplicate keys, values besides strings,
multiple stores, more powerful enumeration, and transactions (maybe others
I'm missing?). Yet, from a novice developers perspective, I don't think
it'd be clear at all what the differences are. I'm not sure how to
reconcile this since LocalStorage is one of the standards supported by
pretty much everyone--including IE.
J
[widgets] Reminder: work on the Updates spec may continue
Hi All, This is a reminder the W3C's Patent Policy [W3C-PP] permits us to continue to work on the Widgets Updates spec [Updates] while the Widgets Updates Patent Advisory Group continues its Charter ([PAG- Charter]): [[ http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-PAG-formation 7.1. PAG Formation ... During the time that the PAG is operating, the Working Group may continue its technical work within the bounds of its charter. ]] Naturally, the above applies to all PAGs, not just the Widgets Updates PAG. -Regards, Art Barstow [W3C-PP] http://www.w3.org/Consortium/Patent-Policy-20040205/ [Updates] http://dev.w3.org/2006/waf/widgets-updates/ [PAG-Charter] http://www.w3.org/2009/03/widgets-pag-charter.html
Re: Denoting privacy-sensitive requests (was: Re: Do we need to rename the Origin header?)
On Wed, Jul 1, 2009 at 7:48 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 5:35 PM: On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. Can you elaborate on the debate or point to an archive? HTML5 will have to enumerate the contexts in which requests are deemed privacy-sensitive (has this been added to HTML5 yet?), however, given that different sites will have different requirements, it may be likely that authors will want the ability to override the default behavior. I think this is a discussion that should be held in the HTML WG, but here is the latest draft of a list that we've discussed at mozilla: https://wiki.mozilla.org/Security/Origin#When_the_Origin_is_served_.28and_when_it_is_.22null.22.29 The document still calls the header Origin, though it should be Sec-From according to Adams latest draft. Also, I see no reason not to simply send null for stylesheet loads. And yes, it's possible that sites will want to override the default behavior. / Jonas
Re: Denoting privacy-sensitive requests (was: Re: Do we need to rename the Origin header?)
Jonas Sicking wrote on 7/1/2009 3:42 PM: On Wed, Jul 1, 2009 at 7:48 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 5:35 PM: On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. Can you elaborate on the debate or point to an archive? HTML5 will have to enumerate the contexts in which requests are deemed privacy-sensitive (has this been added to HTML5 yet?), however, given that different sites will have different requirements, it may be likely that authors will want the ability to override the default behavior. I think this is a discussion that should be held in the HTML WG It'll be difficult for me to participate if it takes place on the HTML WG list due to the restriction on who may join it (I don't qualify). here is the latest draft of a list that we've discussed at mozilla: https://wiki.mozilla.org/Security/Origin#When_the_Origin_is_served_.28and_when_it_is_.22null.22.29 Would you envision those values becoming the default behavior? The column Workaround to Default Behavior wouldn't be needed if authors can control it via HTML5. Also, draft makes mention of sending the RequestType -- is that a proposed header? - Bil
Re: [widgets] Draft Agenda for 2 July 2009 Voice Conference
Regretively, I did not get time to draw up the list of todo's today for PC. I will have it ready for the teleconf and can provide a quick summary during the call. Good news is that well over half the feedback has been responded to and the DoC is mostly up-to-date. Marcos On Wednesday, July 1, 2009, Arthur Barstow art.bars...@nokia.com wrote: Below is the Draft agenda for the July 2 Widgets Voice Conference (VC). Dom, Kai - if you are available for the Testing part of this call, please join us (you can track our progress in #wam). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it may result in a shortened meeting). Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes (maximum) Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 http://irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements 3. PC LC Comments http://dev.w3.org/2006/waf/widgets/ Comment Tracking doc: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20090528/ a. High priority comments; Marcos to supply list in advance of the meeting b. Issue raised by Francois http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0037.html 4. Testing a. Widget Testing wiki http://www.w3.org/2008/webapps/wiki/WidgetTesting b. Dig Sig testing - call for inputs for testable assertion list c. Online Widget Checker service by Dom http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1201.html http://qa-dev.w3.org:8001/widget/ d. PC Test Plan by Dom http://dev.w3.org/cvsweb/2006/waf/widgets/tests/plan.html e. Testing update/status by Kai Hendry f. Test Fest proposal by David Rogers 5. Widgets AE spec: To Do list by Robin http://dev.w3.org/2006/waf/widgets-api/ http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1370.html 6. AOB -- Marcos Caceres http://datadriven.com.au
