Re: File API Feedback
On Mon, Jun 29, 2009 at 11:14 AM, Arun Ranganathan wrote:
> Garrett,
>
> Thanks for taking the time to review this.
>
> Garrett Smith wrote:
>>
>> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
>> Why does the URI contain the date "2006"?
>
> It certainly is confusing, but the '2006' persists as an artifact of the CVS
> repository that I'm using to work on my editor's draft. When ready, it
> should be published to a URL that is more intuitive (and follow how W3C
> usually publishes things).
>>
>> In the "latest public version" there is no getAsDataURI, nor a
>> getDataAsURL. I don't see "url" in the page anywhere.
>>
>>
>
> This is added to the editor's draft.
>>
>> As written, it seems like a synchronous method call. I recall
>> discussions where a few problems with synchronous design mentioned and
>> an asynchronous call was deemed the better approach.
>>
>
> Correct -- that is why the editor's draft reflects that discussion by
> formulating useful APIs as asynchronous ones.
>>
>> In the old "dev" uri, I see the kludge:-
>>
>> void getAsDataURI(in FileAsText callback, [Optional] in
>> FileErrorCallback errorCallback);
>>
>> Can I ask why you've chosen to have the callee invoking callback
>> methods? What about extensibility? To add a progress event, you'd have
>> to pass in an optional "progress" callback, update the entire API.
>> Then a "complete" callback?
>>
>> The "callback" arguments ought to be designed as events. The calling
>> context first subscribes to events, then requests file object to
>> perform the read.
>>
>> DOM Events is the event API that we have and an event API ought to be
>> used. Callback dom properties would be another option to consider in
>> tandem, e.g. myFile.onprogress.
>>
>>
>
> Callbacks are used so that these APIs can behave asynchronously. As drafted
> now, I agree that it is a kludge because the use the error callback is made
> optional. I no longer think it should be optional, and implementations MUST
> call one or the other. The 'null' File data string (or a null FileList) is
> not as instructive as simply having an error callback.
>
That design limits the number of callbacks to one. That one callback
can only be added in the invocation to read.
Instead, allow multiple callbacks to be added with the DOM Events API:
// Add some callbacks
fileObject.addEventListener("complete", readComplete, false);
fileObject.addEventListener("error", readError, false);
fileObject.addEventListener("success", readSuccess, false);
fileObject.getDataAsText();
An asynchronous file read is like an asynchronous XHR, in a way.
> However, I disagree that an event model is necessary for *this*
> specification. Certainly, ProgressEvents can be used with *other* aspects
> of the platform, in conjunction with the File API. They are not necessary
> for asynchronous file data accessors.
>
Lets back up and consider why one might want Events, or why Events make sense.
Events decouple the call to "read" from the notification that the
object is done reading. That allows the File object, "read" method,
and its events, to evolve over time. Decoupling messaging (callbacks)
from commands (behavior) enables independent and concurrently existing
views (interfaces) of the API.
The two ways to implement events are:
1) DOM Events - works and is widely implemented in major browsers.
2) DOM Event handler properties work and even more widely implemented and used
AISB, Events decouple the read from the notification. N callbacks can
be attached, removed, at any time, and the reading can be wrapped in
code that exists elsewhere. This makes for writing cleaner
implementation code. Inelegant APIs proliferate bad design. The
current browser APIs followed by the burgeoning "Ajax" libraries might
be considered an example of such causality.
Progress-type Events are useful because the API is asynchronous.
What if reading the file times out?
If an entire directory is uploaded, as in the Picasa-style example,
when does the "success" callback fire?
1) after all files in "stress" are successfully read
2) upon completion of each file
When reading one large file (a movie, for example), how will the
program provide notification of progress of the upload?
Garrett
Re: An import statement for Web IDL
On Mon, 29 Jun 2009, Maciej Stachowiak wrote: > > It would be nice if we could find a way to make things more rigorous > with a mechanism that's convenient to both spec writers and browser > developers. > > On possibility: we could consistently use modules and have a way to > import by module name, a la Java. Specs could import other modules > wholesale with prose or an IDL fragment at the top of the document. We > could recommend that non-W3C spec specs should use "reverse DNS" style > module prefixes to avoid the possibility of collision. > > This makes the name binding more rigorous than filename-based includes > and should not overly get in the way of implementations or specs. I would rather have just one module for all of the Web platform, since at the end of the day there's only one namespace in JS. However, I do think it'd be nice to have tools to help us check the IDL. Could we have a tool that just scans the textContent out of elements with class=idl, or something? We could give it the URLs of all the specs being developed, and every hour or day or something it could try to fetch all the specs, check that the IDLs still make sense, and if anything bad happens, post an e-mail to some list we all subscribe to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: An import statement for Web IDL
On Jun 28, 2009, at 10:54 PM, Cameron McCormack wrote: The OMG-ish IDL fragments published for W3C specs use C preprocessor- like directives to include other IDL fragments, so that names resolve correctly. For example, http://www.w3.org/TR/DOM-Level-2-Events/idl/events.idl has: [...] That way the IDL processor knows exactly what dependent IDL files it needs to process, and there’s no need to assume that the user of the IDL files has to place the DOM Core and Views IDL files with specific names in the same directory as the events.idl file. Thoughts? Specs having to provide actual IDL files and name them seems like a burden for spec authors, and not helpful to the spec. It's also not helpful for implementations, which do not generally want to have IDL files at whole-spec granularity, but rather per-interface. It would be nice if we could find a way to make things more rigorous with a mechanism that's convenient to both spec writers and browser developers. On possibility: we could consistently use modules and have a way to import by module name, a la Java. Specs could import other modules wholesale with prose or an IDL fragment at the top of the document. We could recommend that non-W3C spec specs should use "reverse DNS" style module prefixes to avoid the possibility of collision. This makes the name binding more rigorous than filename-based includes and should not overly get in the way of implementations or specs. Regards, Maciej
Re: An import statement for Web IDL
On Tue, 30 Jun 2009, Cameron McCormack wrote:
> Cameron McCormack:
> > > I propose that we have an import statement that takes a (possibly
> > > relative) URL. …
>
> Ian Hickson:
> > I'd rather we just implicitly said that all IDL files were imported.
>
> What exactly would “all IDL files” include?
All the IDL files that are supported by the implementation in the relevant
context. So for instance, in a worker's JS context, all the IDLs from Web
Workers, some of the HTML5 ones, the XHR one minus the mention of
Document, etc.
> > and (b) they force a particular file organisation structure on
> > implementations.
>
> I don’t think this is the case. Implementors are of course welcome to
> split up IDL as they see fit for their build processes.
Then they'd have to strip all the includes also and redo it in whatever
way is necessary for their environment.
> My main desire is to be able to declare certain IDL fragments as non-
> conforming. For example, taking this interface from HTML 5:
>
> interface HTMLIFrameElement : HTMLElement {
> attribute DOMString src;
> attribute DOMString name;
> attribute DOMString sandbox;
> attribute boolean seamless;
> attribute DOMString width;
> attribute DOMString height;
> readonly attribute Document contentDocument;
> readonly attribute WindowProxy contentWindow;
> };
>
> Taken in isolation, the names HTMLElement, Document and WindowProxy are
> undefined. There needs to be some way of identifying what those names
> resolve to.
WindowProxy is defined in that very spec (in prose, since it's not
describable in IDL), as is HTMLElement (in IDL). Doucment is defined in
the IDL of a spec that HTML5 normatively references (DOM Core). If we say
that all the IDLs are implicitly imported, the IDL seems unambiguous.
> One way might be to state that the above IDL fragment, even in
> isolation, is a conforming IDL fragment, but then to define another
> conformance class (“conforming set of resolved IDL fragments” or
> something), for which those names do need to resolve to appropriate
> constructs. The set of IDL fragments to use could be defined in the
> HTML 5 spec as prose (identifying all of the fragments in the HTML 5
> spec, plus the relevant ones for DOM Core/Events/Views/etc. interfaces).
Why can't it just be implicitly all of the IDL referenced?
I guess I don't understand what problem we're trying to solve here. It's
not like the IDL above is ambiguous; there's only one interpretation that
I can think of, at least, that is self-consistent.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Fw: An import statement for Web IDL
Dimitry Golubovsky: > I just think that this is a problem separate (although related) from > the forward declarations that we started with, so let's discuss > #include's as well. > > In fact, (maybe I didn't make myself clear) I am for keeping > #include's and therefore having all dependent idl files in a single > stream that compiler consumes just by using a standard preprocessor. I > was annoyed at #include's too at the very first sight (I worked on an > IDL to Haskell compiler back in 2007 and used it in my Haskell to > Javascript compilation project to produce proper type signatures for > DOM methods), but later I realized that they bring more benefits than > inconveniences. IDL files are basically alternative/abstracted syntax > of .h files, and the same principles (#include's and #if/#endif > guards) of handling them IMHO apply. I don’t want to have to require IDL processors to implement a whole C preprocessor. > For the "import" statement proposed: how is it better than #include*? Well, only slightly. It would allow referencing a URL, to avoid hard coding relative local filenames. It would also not need the #ifdef guards. > Besides, one either has to hardcode paths to imported files**, and/or > to implement the same functionality that CPP already has (-I option > for path to include files). Plus, probably every IDL file existing > will have to be rewritten/patched. There are not yet many existing Web IDL files. > So, to my belief, advantages of using #include's are (sorry if this is > too well known): > > * File dependency tree is created automagically. gcc -M will create a > Makefile if needed The author of the IDL fragment needs to be careful about including files correctly at the appropriate place, and preventing files from being included twice. That’s a disadvantage to me. An import statement would just as easily allow dependency analysis. (You couldn’t use gcc -M exactly, though, which I guess is your point.) > * Design of a compiler is simplified because it can just read > everything from stdin: CPP would take care of integration of the > dependent IDL files in a single stream. I don’t want to rely on the CPP. > * Existing files rely upon using #include's, and also do not have > strict rules of sectioning (one file per module, or one per interface, > many modules in a single file are possible). Most existing IDL files aren’t Web IDL files, though. My suggested import statement wouldn’t have strict rules of sectioning either. > * All other advantages CPP gives (that is, macros/conditional > compilation) To me, this seems like complexity that is out of scope for the IDL language. I’d say that you’d be free to use the CPP to process IDL files before handing them off to the IDL processor if you want, but that CPP syntax shouldn’t be part of the IDL language itself. > May I ask you what are the advantages of not using #include's? * Not having to make spec writers publish IDL fragments with hard coded local filenames for dependencies. * Not having to make spec writers be careful about multiple inclusions by using #ifdef guards. * Not requiring the use of an external program (the CPP), or making IDL processor implementors interpret CPP directives. > You wrote on the list: > > - > I don’t think it would be good to require a C preprocessor to get the > same kind of inclusion behavior for Web IDL. But I do think we need to > make sure that names resolve, so we need some kind of mechanism. > - > > But why not? If I am writing an IDL processor it may not be convenient to invoke an external program to perform the CPP processing. > -- > * E. g. a compiler might ignore #ifdef guards and treat #include's as > import statements, that is taking functionality of CPP on itself. I would find it a bit strange, though, if Web IDL defined syntax that looked like C preprocessor directives but which are to be handled like import statements instead. > ** You have URLs in your example; was this the goal to reference > directly to the W3C-stored files, and so would the compiler fetch them > from the Internet (thus requiring a working connection) every time an > IDL file is compiled? I imagined that fetching them would be required only once (or no times at all, if the IDL processor knew about certain common IDL URLs, and had a cache of them). I made a counter-proposal at the end of http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1376.html, which removes import statements (and #includes) and instead relies on some specification outside of the IDL fragments themselves to state what the dependencies are. -- Cameron McCormack ≝ http://mcc.id.au/
Re: An import statement for Web IDL
Cameron McCormack:
> > I propose that we have an import statement that takes a (possibly
> > relative) URL. …
Ian Hickson:
> I'd rather we just implicitly said that all IDL files were imported.
What exactly would “all IDL files” include?
> The problem with import statements is that (a) they require that specs
> actually provide .idl files,
I see this not as a problem, but as a convenience to the implementor.
> and (b) they force a particular file organisation structure on
> implementations.
I don’t think this is the case. Implementors are of course welcome to
split up IDL as they see fit for their build processes.
> In practice WebKit and Gecko both have one .idl per interface, more or
> less, so they couldn't use these import statements anyway.
I don’t think it’s true that they couldn’t use these import statements,
but I agree it might be less convenient, since those files will need to
import the right other IDL files.
My main desire is to be able to declare certain IDL fragments as non-
conforming. For example, taking this interface from HTML 5:
interface HTMLIFrameElement : HTMLElement {
attribute DOMString src;
attribute DOMString name;
attribute DOMString sandbox;
attribute boolean seamless;
attribute DOMString width;
attribute DOMString height;
readonly attribute Document contentDocument;
readonly attribute WindowProxy contentWindow;
};
Taken in isolation, the names HTMLElement, Document and WindowProxy are
undefined. There needs to be some way of identifying what those names
resolve to.
One way might be to state that the above IDL fragment, even in
isolation, is a conforming IDL fragment, but then to define another
conformance class (“conforming set of resolved IDL fragments” or
something), for which those names do need to resolve to appropriate
constructs. The set of IDL fragments to use could be defined in the
HTML 5 spec as prose (identifying all of the fragments in the HTML 5
spec, plus the relevant ones for DOM Core/Events/Views/etc. interfaces).
--
Cameron McCormack ≝ http://mcc.id.au/
Fw: An import statement for Web IDL
[Forwarded with permission.] - Forwarded message from Dimitry Golubovsky - From: Dimitry Golubovsky Date: Mon, 29 Jun 2009 07:27:28 -0400 To: Cameron McCormack Subject: An import statement for Web IDL Cameron, On Mon, Jun 29, 2009 at 1:16 AM, Cameron McCormack wrote: > Dimitry Golubovsky: >> Is the compiler supposed to read the contents of dom.idl while >> compiling svg.idl (which would happen automatically if #include's are >> used)? Or are you tagreting separate compilation, delegating remaining >> resolution to the native compiler/linker? > > Hmm, I suppose if you want to be able to copmile an individual IDL file > then it’s not going to work without a #include of some sort. Maybe it > should allow an import statement (one that doesn’t rely on ensuring you > fence the #include with #ifndef/#endif)? > > I might discuss this on public-webapps, see what other people think. I just think that this is a problem separate (although related) from the forward declarations that we started with, so let's discuss #include's as well. In fact, (maybe I didn't make myself clear) I am for keeping #include's and therefore having all dependent idl files in a single stream that compiler consumes just by using a standard preprocessor. I was annoyed at #include's too at the very first sight (I worked on an IDL to Haskell compiler back in 2007 and used it in my Haskell to Javascript compilation project to produce proper type signatures for DOM methods), but later I realized that they bring more benefits than inconveniences. IDL files are basically alternative/abstracted syntax of .h files, and the same principles (#include's and #if/#endif guards) of handling them IMHO apply. For the "import" statement proposed: how is it better than #include*? Besides, one either has to hardcode paths to imported files**, and/or to implement the same functionality that CPP already has (-I option for path to include files). Plus, probably every IDL file existing will have to be rewritten/patched. So, to my belief, advantages of using #include's are (sorry if this is too well known): * File dependency tree is created automagically. gcc -M will create a Makefile if needed * Design of a compiler is simplified because it can just read everything from stdin: CPP would take care of integration of the dependent IDL files in a single stream. * Existing files rely upon using #include's, and also do not have strict rules of sectioning (one file per module, or one per interface, many modules in a single file are possible). * All other advantages CPP gives (that is, macros/conditional compilation) May I ask you what are the advantages of not using #include's? You wrote on the list: - I don’t think it would be good to require a C preprocessor to get the same kind of inclusion behavior for Web IDL. But I do think we need to make sure that names resolve, so we need some kind of mechanism. - But why not? -- * E. g. a compiler might ignore #ifdef guards and treat #include's as import statements, that is taking functionality of CPP on itself. ** You have URLs in your example; was this the goal to reference directly to the W3C-stored files, and so would the compiler fetch them from the Internet (thus requiring a working connection) every time an IDL file is compiled? PS I am not sending this message to the list, as it contains pieces of our previous off-list conversation, but feel free to forward my comments to the list. Thank you. -- Dimitry Golubovsky Anywhere on the Web - End forwarded message - -- Cameron McCormack ≝ http://mcc.id.au/
Re: Widgets PAG seeks feedback on Widget Updates spec
Hi, sorry, I hadn't seen that this was also posted publicly. On Jun 29, 2009, at 20:23 , Arthur Barstow wrote: The current Widgets-update Specification http://dev.w3.org/2006/waf/widgets-updates/ contains in 12.3 a description on how a widget could update itself by a javascript calling the widget.update() method I wanted to know how important this feature is to the group and how likely it will be that it will find widespread use. The goal is to assess whether it is worthwhile to circumvent the patent also for this self-update feature, which will be a little bit harder than the circumvention for the rest of the Specification. My personal and non-legal opinion on this topic is that that feature simply does not exist. It is mentioned in an example which by definition is not normative (section 1 Conformance further notes "Everything in this specification is normative except for diagrams, examples, notes and sections marked as informative" and the section itself starts with "This section is informative.") It is not defined by Widget Updates and it is not defined by Widget APIs and Events. Furthermore my understanding is that this is the only part of the specification that could possibly infringe Apple's patent, which means that the specification in fact doesn't since that feature is not a part of it (or any other). We can more than very easily drop the example, and in fact the entire section since it is entirely incorrect. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Widgets PAG seeks feedback on Widget Updates spec
Below is a request for feedback from the Chair of the Widget Updates PAG regarding the Widget Updates spec. If you have any questions, I'm sure Rigo will be happy to answer them. -Regards, Art Barstow Begin forwarded message: From: ext Rigo Wenning Date: June 29, 2009 2:03:51 PM EDT To: "Barstow Art (Nokia-CIC/Boston)" Cc: widget-pag Subject: Question on 12.3 Dear Art, this is the message out of ACTION-20 as a chair of the Widgets update PAG, I have the following question to the Webapps Working Group and to those working on the Widgets-update Specification: The current Widgets-update Specification http://dev.w3.org/2006/waf/widgets-updates/ contains in 12.3 a description on how a widget could update itself by a javascript calling the widget.update() method I wanted to know how important this feature is to the group and how likely it will be that it will find widespread use. The goal is to assess whether it is worthwhile to circumvent the patent also for this self-update feature, which will be a little bit harder than the circumvention for the rest of the Specification. Best, Rigo
Re: File API Feedback
Garrett, Thanks for taking the time to review this. Garrett Smith wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml Why does the URI contain the date "2006"? It certainly is confusing, but the '2006' persists as an artifact of the CVS repository that I'm using to work on my editor's draft. When ready, it should be published to a URL that is more intuitive (and follow how W3C usually publishes things). In the "latest public version" there is no getAsDataURI, nor a getDataAsURL. I don't see "url" in the page anywhere. This is added to the editor's draft. As written, it seems like a synchronous method call. I recall discussions where a few problems with synchronous design mentioned and an asynchronous call was deemed the better approach. Correct -- that is why the editor's draft reflects that discussion by formulating useful APIs as asynchronous ones. In the old "dev" uri, I see the kludge:- void getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback errorCallback); Can I ask why you've chosen to have the callee invoking callback methods? What about extensibility? To add a progress event, you'd have to pass in an optional "progress" callback, update the entire API. Then a "complete" callback? The "callback" arguments ought to be designed as events. The calling context first subscribes to events, then requests file object to perform the read. DOM Events is the event API that we have and an event API ought to be used. Callback dom properties would be another option to consider in tandem, e.g. myFile.onprogress. Callbacks are used so that these APIs can behave asynchronously. As drafted now, I agree that it is a kludge because the use the error callback is made optional. I no longer think it should be optional, and implementations MUST call one or the other. The 'null' File data string (or a null FileList) is not as instructive as simply having an error callback. However, I disagree that an event model is necessary for *this* specification. Certainly, ProgressEvents can be used with *other* aspects of the platform, in conjunction with the File API. They are not necessary for asynchronous file data accessors. -- A*
[WebStorage] Property enumeration and checking presence
There is a requirement to obtain the storage mutex prior to performing Storage interface operations on the localStorage DOM attribute. Section 3.4 asks for obtaining the storage mutex during property enumeration, although this term is not used anywhere else in the document. Similarly, it is not clear what is meant by "when checking for the presence of a property" that is any different from the getItem() method. Please clarify. Nikunj http://o-micron.blogspot.com
A+E todo
Hi, here's a list I've collected of things that still need to be done to A +E (I did an editorial pass today). It might not be complete, others are more than welcome to add to it: - viewMode needs to refer to Widgets-WM. Can we agree on what we need to FPWD that one so that there's something to point to? - locale doesn't make much sense: it's a DOMString that is "set to the value of user agent locales", which is an array. Our current algorithm wouldn't allow us to pick one, so it could either be a string joining all of those (as in HTTP) or a sequence. But I'm not at all convinced that this is useful and I recommend dropping it. - for width and height we should be clearer on what is meant by "viewport" - preferences needs to be finalised - onmodechange shouldn't be Function, it should be ModeChangeEvent, and ModeChangeEvent should have [Callback=FunctionOnly] - showNotification() needs a better definiion, getAttention() could perhaps be clarified a little I'll work on some of those tomorrow, feedback is welcome in the meantime. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] editorial style
On Wed, Jun 10, 2009 at 5:03 PM, Anne van Kesteren wrote: > Why are "Reserved Characters", "control characters", and "space characters" > presented in such a different way? It seems that they can be done in a single > style in a single place. > Editorial: Done. I created a new sub-section under "definitions" called "Character Definitions" (hmmm, crappy name, but will do for now). Moved character definitions there and laid them out with an unordered list. There is also a bug (?) in the spec, the reserved characters should also have included the following code points as they are not allowed in file names: U+000A LINE FEED (LF), U+000B LINE TABULATION, U+000C FORM FEED (FF), U+000D CARRIAGE RETURN (CR). I've added them. For the sake of the DoC, is that satisfactory? -- Marcos Caceres http://datadriven.com.au
RE: [widgets] P&C LC#2 comment regarding icons
Following email is not showing up in the archive, so I'm forwarding it. Emails is relevant for the Widget's P&C DoC. Kind regards, Marcos Original Message Subject: RE: [widgets] P&C LC#2 comment regarding icons Date: Mon, 29 Jun 2009 16:26:32 +0200 From: To: CC: , Hi Marcos, I have gone through the 17 June version of spec and found that the issue I reported below is corrected now. Thanks for the reply and for the correction. -regards, -Venkat. -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of ext Marcos Caceres Sent: Monday, June 29, 2009 6:53 AM To: Barstow Art (Nokia-CIC/Boston); Penukonda Venkat (EXT-PSD-MSW/Boston) Cc: public-webapps Subject: Re: [widgets] P&C LC#2 comment regarding icons Hi Venkat, On Fri, Jun 5, 2009 at 8:02 PM, Arthur Barstow wrote: Marcos, All - I can't find a record of this email in the mail list archive. Begin forwarded message: From: "Penukonda Venkat (EXT-PSD-MSW/Boston)" Date: June 2, 2009 11:59:34 AM EDT To: "public-webapps@w3.org" Cc: "Barstow Art (Nokia-CIC/Boston)" Subject: [widgets] P&C LC#2 comment regarding icons Hi, Please refer to the latest Widget PnC spec http://www.w3.org/TR/2009/WD-widgets-20090528/ As per Section 8.10, icon element is not localizable using xml:lang attribute. It can only be folder-based localizable. Section 9, Step-7, Item# 7A is referring to xml:lang of icon elements to determine the valid icon list. Above two sections are contradictory. Most probably the section 9.7 part need to be removed or corrected in the spec. Please let me know if you have any questions. I think this is addressed in the latest editorial draft (I rewrote the section where localized and unlocalized elements are gathered in 9.7): http://dev.w3.org/2006/waf/widgets/ However, can you please confirm that it is all consistent now? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Rule for extracting file data from a file entry
On Wed, Jun 10, 2009 at 4:48 PM, Anne van Kesteren wrote: > "The rule for extracting file data from a file entry is described in this > section." This begs the question what a section is in this specification. It > seems that the next paragraph defines this algorithm rather, not the whole > section. Hopefully this becomes more clear when you restructure it to have > useful sections. > I've added section numbers to all s. Hopefully that makes it more clear that those are sections and not paragraphs, wdyt? > "Exactly how to extract a file from a Zip archive is beyond the scope of this > specification. Instead, implementers must follow the [ZIP] specification's > instructions on how to extract a file from the Zip archive." I suggest to > drop the first sentence as the next sentence makes it in scope (although the > specification defers to another specification for the actual algorithm). > Editorial: Dropped the sentence. > "It is optional for a user agent to extract all the files in a Zip archive at > the same time. The user agent may extract specific files as they are needed > for processing." I think this should be an informative note instead as you > cannot test this assertion so it is irrelevant. > Editorial: Agreed, this is untestable. Changed to a note. > "As a security precaution, implementations are discouraged from extracting > file entries from un-trusted widgets directly onto the file system. Instead, > implementations should consider a virtual file system or mapping to access > files inside" Please do not use RFC 2119 terminology in non-normative text. > I have checked all sections marked as non-normative and made sure I removed 2119 terminology. > I also think it is bad form to put security precautions in a note. I understand, but making the security precaution normative would also result in a non-testable assertion. Do you have a better suggestion as to what I should do here or should I leave it as is (that is, leave it as a note)? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] P&C LC, general comments
For the disposition of comments, let it be known that all issues in this thread (i.e. [1]) have been addressed in the 17 June 2009 Editor's Draft of P&C. That applies also to those found in [2]. (Thread edited to make things smart and easy.) Thanks, Jere [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0727.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1031.html
Re: [widgets] Editorial: 9x Processing
2009/6/10 Anne van Kesteren :
> I think this section should be more clearly (and cleanly) organized. It is
> very hard to tell which parts belong together. As such, "are written with
> more concern for clarity than efficiency" is somewhat ironic :-)
>
It's hard for me to address general comments like this. If there is a
specific part that is confusing, I will try my best to fix it. I can't
do anything if you say that the whole 20-odd page section is
incomprehensible. Other reviewers have not raised issues about the
ordering here. But, like I said, I am happy to make changes to make
things more clear if pointed to a precise issue.
> I'd suggest introducing new sections where that seems appropriate. E.g. "Rule
> for extracting file data from a file entry" clearly seems like it should be a
> section heading rather than just a boldened paragraph.
>
All Processing Rules are marked up as s. They are not boldened
paragraphs. However, to follow stylistic heading conventions, I have
capitalized the appropriate words. Does that help?
I had defined a processing rule within Step 1 ("Rule for Determining
if a Potential Zip Archive is a Zip Archive"), which I have moved to
the appropriate section.
> At the moment it has one section 9.1 and various sections starting with
> "Step" with no number. That should be sorted out.
>
Fixed.
> "Processing Rules" is probably also better renamed to indicate it is just a
> bunch of algorithms used in the section that follows. E.g. "common processing
> infrastructure" or something.
>
I left the title the same as "common processing infrastructure" seems
a bit abstract; however, I rewrote the definition of processing rules
to include your more precise suggestion:
"This section defines various processing rules, which are a set of
common algorithms used by the steps for processing a widget package."
For the sake of the DoC, please confirm if you are satisfied with the
responses above.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
[widgets] P&C comments, 8
Hi Marcos, All, These are a few editorial comments to the latest P&C ED. 6.6 Icons and 9.1/Step7/ 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." 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." 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. 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 P&C is of dynamic nature. So I suggest removing that sentence from the note in order not to create a de-facto standard. 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: Feature names: Typo in example
Hi Marcos, I am ok with the response. Thanks a lot! 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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Monday, June 29, 2009 11:27 AM To: Marcin Hanclik Cc: public-webapps Subject: Re: Feature names: Typo in example Hi Marcin, For the LC DoC, can I get a quick confirmation that you are satisfied with the responses of the WG for this thread. Kind regards, Marcos On Fri, May 29, 2009 at 5:17 PM, Marcos Caceres wrote: > > For the sake of the disposition of comment, please verify that you are > satisfied with the changes and response below. > > On 5/29/09 4:55 PM, Marcin Hanclik wrote: >> >> Hi Marcos, >> >> Thanks. >> Your proposal is generally ok me, feature name is just IRI. >> I have, however, 2 arguments to change your proposal a bit: >> 1. "API:" may be misunderstood, so let's use e.g. "http:" or "ftp:" or >> anything else what is universally known (and hierarchical at the same time) >> now. >> 2. To satisfy the comments from Christian, I would add at least one slash >> in the IRI, e.g. >> "http://example.org/geolocation"; >> As you know in BONDI (just informatively now) we went further and the >> query part of the IRI is used for versioning of the APIs as in >> http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#versioning. >> I do not want to discuss versioning here, but I just would like to vote >> for a slash in the IRI example, to show that IRI is more powerful than just >> to be used as a string (I mean hierarchy etc. and slash may just help here). >> >> What do you think? > > Right, but we don't want delude people into believing that it serves any > purpose beyond helping humans see the hierarchy. How and implementation > treats the URI is a matter for the implementation (in the case of BONDI, > hierarchy indicated by slashes instead of dots might be significant, or it > might not... I don't know.). > > Having said that, I've changed it to a slash to avoid any further confusion. > > Kind regards, > Marcos > > -- 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: Points of order on this WG
On Fri, Jun 26, 2009 at 10:26 AM, Nikunj R. Mehta wrote: > Please don't skimp on due diligence before making such strong statements. > It creates unnecessary friction. More details below. Similarly, I'd ask you to make your points clearer and to read what others say more closely. You didn't address Maciej's points very well, and I think they're definitely worth addressing. > On Jun 25, 2009, at 10:49 PM, Maciej Stachowiak wrote: > > On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote: >> >> On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. >>> Mehta wrote: >>> On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I have proposed to Mozilla a solution that provides access to an organized key-value database such as that provided in the (open source) Berkeley DB. In essence, a database is a simple B-tree - it keeps keys sorted and permits duplicate keys. It is able to find a key or a key prefix, which enables efficient searching through a very large number of items. If we are ambitious (i.e., need more functionality), we can add indexes and joins to this spec. There is unlikely to be an interoperability nightmare, such as that which is the most likely outcome with SQL, it does not mandate the use of any query language, and there is at least 40 years of experience with it, including in highly resource-constrained environments. (There are 200 million copies of Berkeley DB in deployment [1]). >>> >>> This is what so far seems like the best solution to me. I.e. something >>> that is more backend-ish than what a SQL API would be. >>> >>> I'd love to see something that allows you to implement a SQL API on >>> top of. But that also allows you to implement something like MungoDB >>> very effectively. >>> >> >> I doubt you can efficiently or correctly implement SQL on top of a >> Berkeley-DB-style API. >> > > If you are worrying, that's great; we can address your worries. > > Just take a look at the top two hits for "MySQL Berkeley DB". The first one > talks about MySQL with the BDB storage engine - so yes, you can correctly > implement SQL on top of Berkeley DB [1]. The second one talks about MySQL > discontinuing BDB support due to extra-technical reasons, so there are no > efficiency reasons either [2]. > > >> As a side note, it should be noted Berkeley DB itself could not be used by >> WebKit or Gecko to implement the spec, because even though it is open >> source, the license is not compatible with the LGPL. It seems unlikely that >> non-open-source browser engines could use it either, unless they are willing >> to pay Oracle for a commercial license. So it's very important for the spec >> to be clear and detailed, because everyone will have to implement it from >> scratch. >> > > Huh? what? I hope you had read Oracle's BDB license document [3] and open > source FAQ [4]. This is the type of thing I'd expect you to say had those links clearly stated GPL, LGPL, etc compatibility. Am I missing it? Because I don't see anything that makes it clear. > IANAL, but I can get answers for your specific concerns in the context of > open source Berkeley DB. AFAICT, someone like Mozilla would not face any > trouble with the open source license of Berkeley DB. YMMV. What do you mean by your mileage may vary? Are you saying that perhaps it is exactly as Maciej said? > > > >> It's also not clear to me if a BDB-level API is sufficient for developer >> needs. As I understand it, it's basically a giant dictionary with >> unstructured keys and values. So it's not providing much over LocalStorage, >> except for prefix matching and the ability to hold large amounts of records >> or records that are individually large. There's no way to efficiently query >> by one of several fields, as I understand it. >> > > I trust that you are relatively new to storing data with B-trees. They are > at the heart of Oracle's indices so efficiency is out of question. If you > are wondering how can people store complex data items with multiple fields > and repeating values, look at Berkeley DB Java Edition, which supports the > EJB 3 persistence model [5]. FYI, there is no significant difference between > the APIs of BDB Java Edition and the original BDB. They also have identical > licensing requirements. Yes, b-trees (or some variant like b+trees) are used under the hood by basically every database. LocalStorage/SessionStorage could easily be implemented via b-tree's. The underlying implementation really doesn't matter here. What does matter is that localStorage and sessionStorage are a simplified version of what you're proposing. That's what Maciej is bringing up here.
Re: [widgets] P&C LC#2 comment regarding icons
Hi Venkat, On Fri, Jun 5, 2009 at 8:02 PM, Arthur Barstow wrote: > Marcos, All - I can't find a record of this email in the mail list archive. > > Begin forwarded message: > >> From: "Penukonda Venkat (EXT-PSD-MSW/Boston)" >> >> Date: June 2, 2009 11:59:34 AM EDT >> To: "public-webapps@w3.org" >> Cc: "Barstow Art (Nokia-CIC/Boston)" >> Subject: [widgets] P&C LC#2 comment regarding icons >> >> >> Hi, >> >> Please refer to the latest Widget PnC spec >> http://www.w3.org/TR/2009/WD-widgets-20090528/ >> >> As per Section 8.10, icon element is not localizable using xml:lang >> attribute. It can only be folder-based localizable. >> >> Section 9, Step-7, Item# 7A is referring to xml:lang of icon elements to >> determine the valid icon list. >> >> Above two sections are contradictory. Most probably the section 9.7 part >> need to be removed or corrected in the spec. >> >> Please let me know if you have any questions. I think this is addressed in the latest editorial draft (I rewrote the section where localized and unlocalized elements are gathered in 9.7): http://dev.w3.org/2006/waf/widgets/ However, can you please confirm that it is all consistent now? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] P&C LC comments on I18N/L10N
Hi Jere, Fixes and some questions below. I got stuck on your last point, can you please clarify it or suggest more clearly what you want me to do there? On Wed, Jun 3, 2009 at 11:47 AM, wrote: > Marcos, all, > > here's a bunch of comments related to the I18N/L10N related parts of the > Widgets 1.0: Packaging and Configuration spec (Last Call i.e. Working Draft > 28 May 2009). Great! > /1/ Order of material > > >From an editorial standpoint, I think that the "7.2 Examples" subsection > should really be the last one in this section. Right. Moved it. > Information about element-based localization, which now is 8.15, should > appear in section 7, because the concepts are used in Section 8 before they > are even defined. It would be good to have all related info in the same > section. > > My suggestion for the organization of the material is: > > 7 Internationalization and localization > 7.1 Localization guidelines > 7.2 Folder-based localization (used to be 7.3) > 7.3 Element-based localization (used to be 8.15) > 7.4 Localization examples (used to be "7.2 Examples", note new name) Right. I've moved everything and renamed examples > "Localization examples". > This would make the material flow better and have all the concepts defined > before they are used. I will need you to check this before we republish. Is that OK? > Also, the whole of Section 7 should actually appear right before the > processing steps (i.e., after the current Section 8). I moved everything as you suggested. > /2/ Content of examples > > The localization examples are non-normative, but many developers are going > to study them closely, so it pays to fine-tune them a little (and fix a few > bugs). Very true. WRT fine tuning, I'm open to suggestions. Wrt bug fixes... > In the simple example, the second file "/sp/index.html" should be labeled > "/locales/es/index.html". Similarly, in the complex example, "/locales/sp/" > should be "/locales/es". Fixed. > The complex example refers to several files which really have the same > purpose. I think they should also have the same name, otherwise they cannot > be found by the same reference. That is, "/locales/es/gatos.html" should be > called "/locales/es/cats.html". Or is it intentional? Never is:) That is a left over mistake from when we had multiple configs. > In "Fallback Behaviour Example", first paragraph, last sentence should read: > "The purpose of this 'fallback' model is to reduce the number of files that > need to be created in order to achieve localization of a widget package." > (remove 'n' from 'then', add 'in order') fixed (used your text). > > /3/ Folder-based localization > > Suggested addition to the authoring guideline: "A Conformance Checker (CC) > SHOULD issue a warning if there are empty locale folders in the widget > package." > Added. > This statement in the authoring guideline is puzzling: '[That is,] authors > cannot simply put shared files into a language level folder, but need to put > all files needed into the language level folder for the widget to work (for > example, having "a.gif" in both "/locales/zh-Hans/" folder and > "locales/zh").' Isn't this the opposite of what is supposed to happen in the > fallback model? If the same "a.gif" is good for both zh-Hans and zh, it > should be possible for the author to include it just once in "/locales/zh". Yes, this is correct. > If the user's language list includes 'zh-Hans', it will also include 'zh', > as per Step 5. So "a.gif" will be found eventually. > Right. > Replace '"shared1.gif, shared2.gif"' with '"shared1.gif" and "shared2.gif"'. Fixed. > Priority is probably a bad term to use with regard to localized folders. I changed it to: [[ In the example below, assuming the widget's locale is "zh-hans-cn": * The a.gif file in the "zh-Hans-CN" locale folder would be used instead of the a.gif file in the zh-Hans locale folder. * The b.gif file in the zh-Hans locale folder would be used instead of the b.gif file in the zh locale folder. * The c.gif in the zh locale folder would be used instead of the c.gif file root of the widget package. * The d.gif file would always be used from the root of the widget, as it is not associated with any locales and is hence available to all locales. ]] > /4/ The xml:lang attribute > > Does the XML specification state that the values of xml:lang attributes must > be unique across instances of the same element? No. > If yes, it is probably > redundant to repeat that in the context of all the elements in the > configuration document. If not, the statement about uniqueness could still > be factored out, for example to section 8.4, to avoid repetition. Although redundant, I think I will leave this as is. If it's still annoying, we can remove it in CR as it would be an editorial change and it would have no normative impact. Is that OK? > /5/ Processing steps > > Step 3: the concept of "localized config doc" appears in the Configuration > Defaults table,
Re: Feature names: Typo in example
Hi Marcin, For the LC DoC, can I get a quick confirmation that you are satisfied with the responses of the WG for this thread. Kind regards, Marcos On Fri, May 29, 2009 at 5:17 PM, Marcos Caceres wrote: > > For the sake of the disposition of comment, please verify that you are > satisfied with the changes and response below. > > On 5/29/09 4:55 PM, Marcin Hanclik wrote: >> >> Hi Marcos, >> >> Thanks. >> Your proposal is generally ok me, feature name is just IRI. >> I have, however, 2 arguments to change your proposal a bit: >> 1. "API:" may be misunderstood, so let's use e.g. "http:" or "ftp:" or >> anything else what is universally known (and hierarchical at the same time) >> now. >> 2. To satisfy the comments from Christian, I would add at least one slash >> in the IRI, e.g. >> "http://example.org/geolocation"; >> As you know in BONDI (just informatively now) we went further and the >> query part of the IRI is used for versioning of the APIs as in >> http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#versioning. >> I do not want to discuss versioning here, but I just would like to vote >> for a slash in the IRI example, to show that IRI is more powerful than just >> to be used as a string (I mean hierarchy etc. and slash may just help here). >> >> What do you think? > > Right, but we don't want delude people into believing that it serves any > purpose beyond helping humans see the hierarchy. How and implementation > treats the URI is a matter for the implementation (in the case of BONDI, > hierarchy indicated by slashes instead of dots might be significant, or it > might not... I don't know.). > > Having said that, I've changed it to a slash to avoid any further confusion. > > Kind regards, > Marcos > > -- Marcos Caceres http://datadriven.com.au
