Re: File API - Progress - Question about Partial Blob data
Hi all, Le 29/08/2013 01:25, Aymeric Vitte a écrit : The Streams API says for now This event handler should mimic the |FileReader.onprogress| http://dev.w3.org/2006/webapi/FileAPI/#dfn-onprogress event handler The second proposal is not very explicit for now but there is a read resolver. This discussion seems to be the same as the Overlap between StreamReader and FileReader thread. Now, I don't know what is the plan for the File API V2/Streams API (Promises? Schedule?) probably I am missing some details but I don't see what's the difficulty to replace the partial Blob as it is today by delta data (both for Files and Streams), the API does not have to care about non consumed data since the reader/parser/whatever_handles_the_data takes care of it (as long as delta data passed to the callback are not modified by the read, cf the example I gave for the above thread) I fully agree with Aymeric. Can someone summarizes what's the history behind XHR that makes it hard to change (or better give an example that would break)? I would like to see progress on the Stream API (how can I help?) because it solves one use case on which I'm working: download and aggregation of resources via XHR and in parallel use of the aggregation via a media element. This is similar to the MediaSource approach but for simpler progressive download cases. This is a bit different from the use cases I've seen on this list. The data is not consumed by JavaScript calls but by the browser directly. The JS would just use a series of StreamBuilder.append calls. Cyril Regards, Aymeric Le 27/08/2013 01:37, Kenneth Russell a écrit : On Fri, Aug 23, 2013 at 8:35 AM, Arun Ranganathana...@mozilla.com wrote: On Aug 22, 2013, at 12:07 PM, Jonas Sicking wrote: I think you might have misunderstood my initial comment. I agree that the current partial data solution is not good. I think we should remove it. I'd really like other implementors to weigh in before we remove Partial Blob Data. Cc'ing folks who helped with it. Eric Urhane asked me to follow up on this thread on behalf of Gregg Tavares who unfortunately left Google. The current spec for partial blob data is too inefficient, because it accumulates all of the data since the beginning of the download. This is not what's desired for streaming downloads of large data sets. What's needed is a way to retrieve the data downloaded since the last query. Several web developers have asked about this recently as they're trying to stream ever larger 3D data sets into the browser. I think we should instead create a better solution in v2 of the API which is based on something other than FileReader and which has the ability to deliver data on the form of here's the data that was loaded since last notification. I agree that we should do a better way. Agreed. It would be really good to finally make progress in this area. It sounds like Microsoft's Streams API proposal at https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm or tyoshino's Streams with Promises propsal at http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html are two leading contenders. I personally don't care which flavor is chosen so long as things move forward. Microsoft's proposal does seem more fully fleshed out. (At least, it contains fewer instances of the word blah. :) ) -Ken -- jCore Email :avi...@jcore.fr Peersm :http://www.peersm.com iAnonym :http://www.ianonym.com node-Tor :https://www.github.com/Ayms/node-Tor GitHub :https://www.github.com/Ayms Web :www.jcore.fr Extract Widget Mobile :www.extractwidget.com BlimpMe! :www.blimpme.com -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: Streams and Blobs
Hi Anne, Le 26/02/2013 17:34, Anne van Kesteren a écrit : On Tue, Feb 26, 2013 at 3:01 PM, Cyril Concolato cyril.concol...@telecom-paristech.fr wrote: Hi Anne, Did you mean to reply just to me? No, adding the list. * moz-blob Is this the same as blob specified in the XHR2 draft [1]? No, it's available during LOADING. Ok. Is moz-chunked-arraybuffer supposed to be the same as arraybuffer of the draft? No. The draft only exposes on load, which is what browsers are supposed to implement... I was confused when reading only: Thearraybuffer response entity bodyis an|ArrayBuffer http://www.khronos.org/registry/typedarray/specs/latest/#ARRAYBUFFER|representing theresponse entity body https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body. and then: Theresponse entity bodyis the fragment of theentity body http://tools.ietf.org/html/rfc2616/#section-7.2of the response received so far (LOADING https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-loading) or the completeentity body http://tools.ietf.org/html/rfc2616/#section-7.2of the response (DONE https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-done). It is true that step 1 in the otherwise statement in 4.7.8 (if the state is not DONE, return) is clear. It would probably be better if the text was only in one place. By chunked do you mean that a given ArrayBuffer does not contain any data overlapping with the previous or following ArrayBuffer (if any) as opposed to blob which gives you the concatenation of the previous Blob and the new data, right? That is chunked yes. What you call blob is what I call incremental and does not exist in the draft. Also, do you intend to have one ArrayBuffer per chunk received in HTTP1.1, or will the two notions be independent (1 ArrayBuffer possibly gathering data from 2 or less than 1 HTTP chunk)? It will depend on when you last get .response. At least that is how chunked works as I understand it. It may be the same use case, I'm not sure what you mean by transferred vs. read. One use case is to have XHR as a source of data for MediaSource. In this case, you want to have independent non-concatenated buffers and pass them to the MediaSource object. Yeah, I think that is the give me the last buffer case without any storing like chunked does. Ok, I think I agree with you. In summary, we'd have: blob: .response = full data as a Blob, on DONE, null otherwise. arraybuffer: .response = full data, on DONE, null otherwise. moz-blob: .response = a different blob object containing partial data (not overlapping with previous/next blobs), on LOADING and DONE, null otherwise. moz-chunked-arraybuffer: .response = a different arraybuffer object containing partial data (non-overlapping), on LOADING and DONE, null otherwise. moz-chunked-text: .responseText = a different string object containing partial data (non-overlapping), on LOADING and DONE, null otherwise. Is that correct? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: CfC: publish FPWD of Streams API; deadline February 2
Hi all, Le 27/01/2013 03:23, Arthur Barstow a écrit : Feras would like to publish a First Public Working Draft (FPWD) of Streams API and this is a Call for Consensus (CfC) to do so, using the following ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by February 2 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. Feras - with Chrome(24) it appears the ED is not loading a W3C stylesheet (looks much better with FF 19.0). Perhaps this is related to the hg http/https mentioned yesterday in [1]. Institut Telecom approves the publication as a FPWD. Regards, Cyril -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0149.html -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: [File API] About Partial Blob Data, XHR and Streams API
Hi Arun, Le 22/01/2013 15:04, Arun Ranganathan a écrit : Hi Cyril, 1) I'm wondering why in progressive mode, does the spec say: ||partial Blob data is an |ArrayBuffer|[TypedArrays http://dev.w3.org/2006/webapi/FileAPI/#TypedArrays] object consisting of the bytes|loaded|so far. Why isn't it the bytes loaded since the previous progress event? AR: It is always a new ArrayBuffer. The phraseology so far could be replaced by bytes loaded since the previous progress event though I'm not always sure that will be the case. I understood from Jonas' answer that it was a new ArrayBuffer. What remained unclear was the content of the ArrayBuffer: all the data from the beginning of the read operation (which was problematic), or only the data read since the previous progress event (which I prefer). If, as you say, this is latter option, then please fix the spec. as so far is very ambiguous. In my use case, the binary data resource might have an infinite size, in which case the result objects will grow forever. I looked at the Streams API [1] to see if there was any difference for that but I couldn't see any. Reading with the FileReader interface a Stream (dynamic length) or a Blob (fixed length) seems to always return the whole content. AR: Here, do you mean, you never get a progressevent other than load and loadend in your tests? No, I meant that the Streams API uses the same approach as the File API: This method should mimic|FileReader.readAsArrayBuffer()| http://dev.w3.org/2006/webapi/FileAPI/#readAsArrayBufferSyncSection So, I understood reading so far that you would get the content of the stream read so far from the beginning at each time, which is practically unusable. If the FileAPI spec is fixed, the Streams API is fixed as well. Certainly, if you had binary data of infinite size, you'll get several result objects. The file API, particularly FileReader, shouldn't be used in streaming scenarios. I disagree. The File API combined with XHR should be fine for reading (large) files for which the size is known when making the request but still delivered using HTTP streaming approaches. The Streams API and XHR should be fine for the same thing but for (infinite) files for which you don't know the size (chunked transfer to simulate IceCast/ShoutCast). A possible problem is when the apps want to receive the exact chunks created by the server (point 2 in my previous email) which the FileReader API doesn't preserve. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: [File API] About Partial Blob Data, XHR and Streams API
Hi Jonas, Le 1/18/2013 11:14 AM, Jonas Sicking a écrit : On Thu, Jan 17, 2013 at 1:56 AM, Cyril Concolato cyril.concol...@telecom-paristech.fr wrote: Hi all, Reading the File API, it is not clear to me what the behavior is when reading partial Blob data. The spec says: Partial Blob data is the part of the File or Blob that has been read into memory currently; when processing the read method readAsText, partial Blob data is a DOMString that is incremented as more bytes are loaded (a portion of the total) [ProgressEvents], and when processing readAsArrayBuffer partial Blob data is an ArrayBuffer [TypedArrays] object consisting of the bytes loaded so far (a portion of the total)[ProgressEvents]. Does this mean that the result object is the same or it is a new object each time there is a progress event ? In the case of a DOMString, it could be the same object incremented but if it is an ArrayBuffer, since it is immutable, it cannot be incremented. Strings in JS are immutable. So it will always be a new string. So in the case the final length of the Blob is not known yet (e.g. chunked XHR), result has to be a new object each time. Am I wrong here? If not, could you clarify the spec ? The size of a Blob is always known. The .size property never returns 'undefined' or 'null' or anything like that. XHR never returns a Blob object until it knows what size of Blob object to create. Thanks for the clarification. So if I understand correctly, the result attribute of a FileReader object at each progress event is a different object. Is that right? I also have a few more questions about the use of XHR and FileReader. The use case I'm working on is the HTTP Streaming of a live binary data (typically video and audio but not only) using chunked XHR. 1) I'm wondering why in progressive mode, does the spec say: ||partial Blob data is an |ArrayBuffer|[TypedArrays http://dev.w3.org/2006/webapi/FileAPI/#TypedArrays] object consisting of the bytes|loaded|so far. Why isn't it the bytes loaded since the previous progress event? In my use case, the binary data resource might have an infinite size, in which case the result objects will grow forever. I looked at the Streams API [1] to see if there was any difference for that but I couldn't see any. Reading with the FileReader interface a Stream (dynamic length) or a Blob (fixed length) seems to always return the whole content. I also looked at the WHATWG XHR spec [2] and its use of responseType stream and in this case, it seems that the response attribute is a Stream object containing the fragment of theentity body http://tools.ietf.org/html/rfc2616/#section-7.2of the response received so far. So this is not useful either. 2) I'm wondering also why wasn't the design made to enable accessing the content of each HTTP chunk directly within the XHR object. In a video streaming use case, the server might have carefully created the (video) chunks so that an application can use them independently without parsing them (typically passing them to the decoder through the MediaSource Extension API [3]). With the FileReader approach, the application will have to parse each progress event result object to determine meaningful chunks for the video decoder. Regards, Cyril [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#streamreader-interface [2] http://xhr.spec.whatwg.org/#the-responsetype-attribute [3] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
[Streams API] typo
Hi all, I noticed a typo in the W3C Editor's Draft 25 October 2012 of Streams API (section 2.2): not allow and future reads should be not allow *any* future reads. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
[File API] About Partial Blob Data
Hi all, Reading the File API, it is not clear to me what the behavior is when reading partial Blob data. The spec says: Partial Blob data is the part of the |File| http://dev.w3.org/2006/webapi/FileAPI/#dfn-file or |Blob| http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob that has been read into memory /currently/; when processing the read method http://dev.w3.org/2006/webapi/FileAPI/#read-methods |readAsText| http://dev.w3.org/2006/webapi/FileAPI/#dfn-readAsText, partial Blob data is a |DOMString| that is incremented as more bytes are |loaded| (a portion of the |total|) [ProgressEvents http://dev.w3.org/2006/webapi/FileAPI/#ProgressEvents], and when processing |readAsArrayBuffer| http://dev.w3.org/2006/webapi/FileAPI/#dfn-readAsArrayBuffer partial Blob data is an |ArrayBuffer| [TypedArrays http://dev.w3.org/2006/webapi/FileAPI/#TypedArrays] object consisting of the bytes |loaded| so far (a portion of the |total|)[ProgressEvents http://dev.w3.org/2006/webapi/FileAPI/#ProgressEvents]. Does this mean that the result object is the same or it is a new object each time there is a progress event ? In the case of a DOMString, it could be the same object incremented but if it is an ArrayBuffer, since it is immutable, it cannot be incremented. So in the case the final length of the Blob is not known yet (e.g. chunked XHR), result has to be a new object each time. Am I wrong here? If not, could you clarify the spec ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: RfC: LCWD of Progress Events; deadline September 1
Le 02/09/2011 15:32, Arthur Barstow a écrit : Cyril - unless we hear otherwise from you, we will assume you are satisfied with the way your comments have been addressed: http://dev.w3.org/2006/webapi/progress/ Anne - assuming Cyril is agreeable with the way his comments were addressed, please update the ED to reflect a CR publication (e.g. add CR exit criteria you used in rev 1.25) and notify me when you are done so I can start a CfC to publish a CR. I agree. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: RfC: LCWD of Progress Events; deadline September 1
Le 14/08/2011 14:05, Anne van Kesteren a écrit : On Wed, 10 Aug 2011 09:36:33 +0200, Cyril Concolato cyril.concol...@telecom-paristech.fr wrote: Le 09/08/2011 19:34, Arthur Barstow a écrit : On August 9, WebApps published LCWD #2 of the Progress Events spec: http://www.w3.org/TR/2011/WD-progress-events-20110809/ Section 2.1: If this is for some reason not possible prefix the extension in some way and start the prefix with an uppercase letter. E.g. if company Foo wants to add a private method bar() it could be named FooBar() to prevent clashes with a potential future standardized bar(). This sentence in hard to read and unclear. Please rephrase/fix it. Suggestions? The sentence is so unreadable that it's hard to suggest something. It starts with a general statement but ends with an example. I think it should be split in two: general statement with a full sentence (now it seems to end at letter ?) and then add the example. Also add to before prefix and start. Section 4.2: It should indicate what the requirements for other specifications are to define properly the use of these events. There are no requirements. When reading that: The editor is encouraged to define it in a way consistent with this, it did not seem so. Section 4.3: Why aren't the names of events, and the instant and number of times they are dispatched, not normatively defined ? This would be beneficial for consistency in the web platform, wouldn't it? Because it very much depends on the context. Example ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: [XHR] support for streaming data
Hi Charles, Le 10/08/2011 23:19, Charles Pritchard a écrit : On 8/9/2011 1:00 AM, Cyril Concolato wrote: Hi Charles, I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. I don't know what you're referring to. PDF 7.5.8.3 Cross-Reference Stream Data PDF supports byte offsets, links and SMIL. Thanks for the reference. I suppose I was referring more to the MP4Box work than GPAC, though they do work in harmony. MP4 has chunk offsets, and GPAC includes SVG discard support. I believe that MP4Box stores, and GPAC reads fragments of a large SVG file throughout the MP4 stream, in a limited manner, similar to how a PDF processes streams. They both allow someone to seek and render portions of a large file, without loading it all into memory. From the article: We have applied the proposed method to fragment SVG content into SVG streams on long-running animated vector graphics cartoons, resulting from the transcoding of Flash content... NHML descriptions were generated automatically by the cartoon or subtitle transcoders. ... the smallest amount of memory [consumed] is the 'Streaming and Progressive Rendering'. The memory consumption peak is reduced by 64% SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. The details of how we can do it is here: http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=7129 Basically, for long running SVG animations (e.g. automatic translation from Flash to SVG), it is interesting to load only some SVG parts when they are needed and to discard them (using the SVG Tiny 1.2 discard element), when they are no longer needed. For that, we use an auxiliary file that indicates how to fragment the SVG file into a stream, giving timestamps to each SVG file fragment. That auxiliary file is then used to store the SVG fragments as regular access units in MP4 files, we use MP4Box for that. The manipulation of those fragments for storage and playback is then similar to what you would do for audio/video streams. We don't do transcoding for SVG fragments but for instance individual gzip encoding is possible. I think an interesting use case for XHR would be to be able to request data with some synchronization, i.e. with a clock reference and timestamp for each response data. Some part of that could be handled via custom HTTP headers; though it's certainly a bit of extra-work, much as implementing seek over http can be work. Custom HTTP headers or other HTTP Streaming solutions (e.g. MPEG DASH). That's the benefit of storing the SVG as fragments in an MP4. At the time we wrote the paper we were able to stream the SVG with an unmodified Darwin Streaming Server using the RTP protocol. I believe there would be no problem in streaming the SVG in an MP4 with an unmodified HTTP Server using the DASH approach. I haven't tried though. I'll keep thinking about the case you brought up. I do believe timestamps are currently available on events, relating to when the event was raised. What do you mean by a clock reference? That's a general concept when synchronizing multiple media streams, possibly not all synchronized together, you need to group them by their common clock. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: RfC: LCWD of Progress Events; deadline September 1
Le 09/08/2011 19:34, Arthur Barstow a écrit : On August 9, WebApps published LCWD #2 of the Progress Events spec: http://www.w3.org/TR/2011/WD-progress-events-20110809/ Section 2.1: If this is for some reason not possible prefix the extension in some way and start the prefix with an uppercase letter. E.g. if company Foo wants to add a private method bar() it could be named FooBar() to prevent clashes with a potential future standardized bar(). This sentence in hard to read and unclear. Please rephrase/fix it. Section 4.2: It should indicate what the requirements for other specifications are to define properly the use of these events. Section 4.3: Why aren't the names of events, and the instant and number of times they are dispatched, not normatively defined ? This would be beneficial for consistency in the web platform, wouldn't it? Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: [XHR] support for streaming data
Hi Charles, I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. I don't know what you're referring to. SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. The details of how we can do it is here: http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=7129 Basically, for long running SVG animations (e.g. automatic translation from Flash to SVG), it is interesting to load only some SVG parts when they are needed and to discard them (using the SVG Tiny 1.2 discard element), when they are no longer needed. For that, we use an auxiliary file that indicates how to fragment the SVG file into a stream, giving timestamps to each SVG file fragment. That auxiliary file is then used to store the SVG fragments as regular access units in MP4 files, we use MP4Box for that. The manipulation of those fragments for storage and playback is then similar to what you would do for audio/video streams. We don't do transcoding for SVG fragments but for instance individual gzip encoding is possible. I think an interesting use case for XHR would be to be able to request data with some synchronization, i.e. with a clock reference and timestamp for each response data. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Le 11/02/2010 17:33, Robin Berjon a écrit : Hi Cyril, On Feb 11, 2010, at 14:03 , Arthur Barstow wrote: On Feb 10, 2010, at 10:22 AM, ext Cyril Concolato wrote: Dear Mr. Barstow, We can do so provided you agree to never again call me Mr. Barstow :-). Yeah, we wouldn't want to anger Mr. Barstow. Seriously though, yes we can add it to the AOB section of today's agenda. Please join us if you can. We discussed this on the call today and decided that it would be better if you were around while we discussed it; would it be possible for you to join our next call? I would be glad to join. When is the next call ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Dear Mr. Barstow, As indicated in the mails about MPEG-U, I would like to request that the WG discusses the MPEG liaison regarding widgets. Could you add it to the agenda ? Best Regards, Cyril Concolato Le 10/02/2010 14:29, Arthur Barstow a écrit : Below is the draft agenda for the 11 February Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open and Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/04-wam-minutes.html Logistics below. -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. LC of XML Signatures spec published 4 Feb: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0531.html 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ CR Implementation Report: http://dev.w3.org/2006/waf/widgets/imp-report/ a. Important Test Suite Updates by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0485.html b. Action-486: Create ITS test case(s) for the PC test suite http://www.w3.org/2008/webapps/track/actions/486 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. API - openURL security considerations by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0501.html b. TWI: comments by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0479.html c. window object by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0476.html 5. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure to test the WARP spec http://www.w3.org/2008/webapps/track/actions/490 6. AOB a. Charter renewal - please send comments to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0493.html Comments from Scott Wilson: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0525.html Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets-twi] window object
Le 08/02/2010 13:29, Robin Berjon a écrit : On Feb 5, 2010, at 16:18 , Marcos Caceres wrote: On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr wrote: So I'm wondering how should the widget object be implemented in a UA that does not support the window object ? Yeah, that's a tough one... the spec says: For a widget instance, a user agent MUST expose a unique object that implements the widget interface to author scripts. It does not give any guidance as to how the interface must be exposed. But then again, SVG supports the Window object (minimally defined in http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a widget field there ought to be straightforward. My mistake. I had not realized that. But again, the question is why put the widget object on the window object, apart from it being a black hole. Why not put it in the global object. What's wrong with that? It would easier to specify. What's the benefit of using the window object? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] TWI: comments
Hi Marcos,
Le 08/02/2010 16:56, Marcos Caceres a écrit :
On Thu, Feb 4, 2010 at 10:19 PM, Cyril Concolato
* The spec says:
When an object implementing the Widget interface is instantiated, if a user
agent has not previously associated a storage area with the instance of a
widget, then the user agent must initialize the preferences attribute.
What happens if the UA has already associated a storage area ? It should
probably say that no initialization of the preferences attribute is made but
the associated storage area can be used using the Storage interface, no ?
Right, I've adapted your text to read:
When an object implementing the Widget interface is instantiated, if
a user agent has not previously associated a storage area with the
instance of a widget, then the user agent must initialize the
preferences attribute.
If a user agent has previously associated a storage area with a widget
instance, the user agent must not re-initialize the preferences
attribute unless explicitly requested to do so by the end-user or for
security reasons. Instead, the previously associated storage area (or
an equivalent clone) can be accessed using the Storage interface.
Does that make any sense?
Yes it does.
... hmm... seems that Storage is tied to Window... bah. This goes back
to my previous email [1] about the window object. I think we need to
just bite the bullet and just put the Window dependency in :(
See my answer to Robin, I'm not sure to understand the benefits of that choice.
* What is the return value for the openURL method when there is a scheme
handler associate to the IRI ? When there is none, the text says the method
returns void. I think it also returns void so I wonder what's the point of
the paragraph.
Right. This whole openURL section needs a minor clean-up: there is a
bit or redundancy there. Let me work on that an get back to the WG.
Thanks.
* The IDL spec indicates that the preference attribute implements the
Storage interface, but I can't find a 'real' sentence saying it. I find:
Note: A user agent can support the Storage interface on DOM attributes
other than the preferences attribute (e.g., a user agent can to support the
[WebStorage] specification's localStorage attribute of the window object in
conjunction to the preferences attribute) but this is a note, hence not
normative.
Well spotted! The definition of preference now reads:
The preferences allows authors to manipulate a storage area that is
unique for the instance of a widget. It does this by implementing the
Storage interface specified in [WebStorage].
Good.
I suggest that you add an additional sentence. Also, the given example is
not really clear because it does not show the relationship between a
config.xml document with preference elements and the associated script and
storage.
That's a good point. I've added another example to the spec. Can you
please take a look?
Finally, can you clarify if the usage of getItem / setItem such as in
widget.preferences.getItem('foo'); and widget.preferences.setItem('foo',
'dahut'); is allowed or if only the brackets notation
(widget.preferences['foo']) is allowed. Maybe by adding an example ?
As of WebIDL , I believe the notations are equivalent. Regardless, I
have added an example. Please see the spec.
Can you point me to the right place because I can't find the new examples in:
http://dev.w3.org/2006/waf/widgets-api/
Regards,
Cyril
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/
Re: MPEG-U
Robin, Le 09/02/2010 13:41, Robin Berjon a écrit : Hi Cyril, On Feb 9, 2010, at 10:20 , Cyril Concolato wrote: Le 04/02/2010 13:35, Robin Berjon a écrit : It would be a lot simpler if the secretariat would just send an email to this list! I agree with you it would be much simpler, but that's not my choice. Well, you could vote with your feet ;-) Apparentyl, the attachement has been removed by a W3C member. I don't understand the reasons. Anyway, the WG should be able to process it. Can I request that this topic be discussed at the next conference of the WG? We certainly can, but our minutes are public — do we have to discuss it unrecorded? I don't think so. All the documents related to MPEG-U (unfortunately, except for liaisons) being public documents [1] this shouldn't be a problem. Cyril [1] http://mpeg.chiariglione.org/working_documents.htm#MPEG-U -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets-twi] window object
Le 05/02/2010 16:18, Marcos Caceres a écrit :
On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr wrote:
Hi all,
After PC, I'm looking now at the Widget Interface spec, in particular to
check the test suite and produce the implementation report. I have a problem
with the spec. In GPAC, we implement only SVG not HTML5, with the Window
object.
Hmm... to support SVG, what we should do is externalize the javascript
of each test. Then just use a script element to include the same code
into both files. Do you think you could help me do this?
Basically, what we would need to do is:
1. check if the current scripts work in an SVG context - and fix if they don't.
2. make the SVG templates (index.svg).
3. externalize all the JS (call them all test.js).
4. Replace all the HTML files.
Here is a first try. I've made the test.js with the widget related code and the
SVG/HTML related code is in the SVG/HTML file. However, since there is no
explicit normative way to implement the widget object when the start file is
SVG I had to decide on one. So I've added the following code in test.js:
var w;
if (typeof(window.widget) != undefined) {
w = window.widget;
} else if (typeof(widget) != undefined) {
w = widget;
}
Is it ok?
I'm not sure what we will do with all the automatically generated
tests. We will need some guidance there from Dom, as I don't know how
that generator works.
So I'm wondering how should the widget object be implemented in a UA
that does not support the window object ?
Yeah, that's a tough one... the spec says:
For a widget instance, a user agent MUST expose a unique object that
implements the widget interface to author scripts.
It does not give any guidance as to how the interface must be exposed.
What was the rationale for having the widget object as an attribute of the
window object. Why not put in the global object, this would avoid having to
handle it differently in each language?
Cyril
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/
widget xmlns=http://www.w3.org/ns/widgets;
id=test:au
nameTest au/name
descriptionTesting assertion ta-aa/description
preference name=test1 value=abc123 /
preference name=test2 value=protected readonly=true /
/widgetTitle: Test au
FAIL
Test did not run.
attachment: index.svg
test.js
Description: JavaScript source
[widgets-twi] window object
Hi all, After PC, I'm looking now at the Widget Interface spec, in particular to check the test suite and produce the implementation report. I have a problem with the spec. In GPAC, we implement only SVG not HTML5, with the Window object. So I'm wondering how should the widget object be implemented in a UA that does not support the window object ? Best regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] TWI: comments
Hi all,
While trying to implement the widget interface spec [1], I found two typos:
- a user agent can to support = a user agent can support
- missing closing parenthese in conjunction to the preferences attribute).
I have also some remarks/questions:
* A user agent whose start file implements [HTML5]'s Window interface MUST
...
The start file does not implement anything. The user agent implements. I
suggest to change it to something like:
User agent implementing the [HTML5]'s Window interface MUST ...
* Section 5. is called Widget Interface but it starts by saying The widget object provides
It think it should say Objects implementing the widget interface provide ...
* The step 1 in the initialization of the preference attribute algorithm which says Establish
the instance of a widget for this widget and create a storage area that is unique for the
origin. should probably say unique for the origin and for that instance.
* The spec says:
When an object implementing the Widget interface is instantiated, if a user agent
has not previously associated a storage area with the instance of a widget, then the user
agent must initialize the preferences attribute.
What happens if the UA has already associated a storage area ? It should
probably say that no initialization of the preferences attribute is made but
the associated storage area can be used using the Storage interface, no ?
*In case two instances of the same widget package are loaded, modified (e.g.
weather in Paris and in New York) and then closed, how does the UA retrieve the
associated storage area when one is reloaded ? I don't think it can be
specified but I think you should probably add a note saying that it is
implementation specific, for example by asking the user what previous instance
it want to start first.
* What happens to the storage event fired by the setItem or removeItem
methods when the UA does not implement the window object ?
* What is the return value for the openURL method when there is a scheme
handler associate to the IRI ? When there is none, the text says the method
returns void. I think it also returns void so I wonder what's the point of the
paragraph.
* The IDL spec indicates that the preference attribute implements the Storage
interface, but I can't find a 'real' sentence saying it. I find:
Note: A user agent can support the Storage interface on DOM attributes other than
the preferences attribute (e.g., a user agent can to support the [WebStorage]
specification's localStorage attribute of the window object in conjunction to the
preferences attribute) but this is a note, hence not normative.
Return the Storage object associated with that widget instance's preferences
attribute. but that's not really explicit.
Implement the Storage interface on the storage area, and make the preferences attribute a
pointer to that storage area. but this isn't as clear as The UA MUST support the
Storage interface on the preferences attribute or similar...
I suggest that you add an additional sentence. Also, the given example is not
really clear because it does not show the relationship between a config.xml
document with preference elements and the associated script and storage.
Finally, can you clarify if the usage of getItem / setItem such as in
widget.preferences.getItem('foo'); and widget.preferences.setItem('foo',
'dahut'); is allowed or if only the brackets notation
(widget.preferences['foo']) is allowed. Maybe by adding an example ?
Regards,
Cyril
[1] http://www.w3.org/TR/2009/CR-widgets-apis-20091222/
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/widgets/
Re: MPEG-U
Dear all, I've been informed by the ISO secretariat that the liaison from MPEG was sent to the W3C and that the right persons this time have received it. Is it correct? Can you tell me what the next step is ? Has the group discussed it ? What is the opinion of the group ? If not, when will it be discussed ? Regards, Cyril Le 20/01/2010 17:24, Doug Schepers a écrit : Hi, Cyril- Cyril Concolato wrote (on 1/20/10 12:24 AM): Le 13/01/2010 19:59, Doug Schepers a écrit : Cyril Concolato wrote (on 1/13/10 10:37 AM): Yes, you're right, the problem is that liaisons usually are not considered as public documents so the secretariat or MPEG members are not allowed to make them public. ... Anyway, MPEG is meeting next week, I'll raise your questions and try to have MPEG make a formal answer. Could you please make sure that the secretariat sends the email to team-liais...@w3.org, CCing Steven, Mike, and me, as the Team Contacts for the WebApps WG, and Philippe Le Hegaret as Interaction Domain Lead? It's not appropriate to email Tim Berners-Lee for liaisons at this level, though if they insist, I suppose they can include him. We need to make sure that these liaisons are dealt with in a timely manner. I would greatly appreciate if you could have the secretariat send an immediate acknowledgment email to the above email addresses, just to make sure that the process is understood and accepted, before sending the liaison itself. Could you please request that right away? I know you are doing what you can to make sure the communication channels are clear, so I appreciate your help. Just for clarification. I don't know yet if the liaison can be sent to a public mailing list. But if it is possible, is it preferable to send it directly to the public mailing list or to list of persons you mentioned? My personal preference is that the technical discussion happen on public-webapps, of course, but that is a dialog that should be carried on by people like you, who are in both organizations. Liaisons from MPEG (and other organizations) tend to be formal documents (usually in Word or PDF format), and require formal documents in return, so we need to address that in a separate channel, after the technical discussion has taken place. If it is possible to have these liaisons sent to the public list as well as the people and lists I mention above, please do so; failing that, please ask them to send the liaisons to member-webapps as well. If we need to draw up a Memorandum of Understanding regarding this, please let us know. Thanks again. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: MPEG-U
Hi Doug, Le 13/01/2010 19:59, Doug Schepers a écrit : Hi, Cyril- Cyril Concolato wrote (on 1/13/10 10:37 AM): Yes, you're right, the problem is that liaisons usually are not considered as public documents so the secretariat or MPEG members are not allowed to make them public. ... Anyway, MPEG is meeting next week, I'll raise your questions and try to have MPEG make a formal answer. Could you please make sure that the secretariat sends the email to team-liais...@w3.org, CCing Steven, Mike, and me, as the Team Contacts for the WebApps WG, and Philippe Le Hegaret as Interaction Domain Lead? It's not appropriate to email Tim Berners-Lee for liaisons at this level, though if they insist, I suppose they can include him. We need to make sure that these liaisons are dealt with in a timely manner. I would greatly appreciate if you could have the secretariat send an immediate acknowledgment email to the above email addresses, just to make sure that the process is understood and accepted, before sending the liaison itself. Could you please request that right away? I know you are doing what you can to make sure the communication channels are clear, so I appreciate your help. Just for clarification. I don't know yet if the liaison can be sent to a public mailing list. But if it is possible, is it preferable to send it directly to the public mailing list or to list of persons you mentioned? Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: MPEG-U
Hi Robin, Le 12/01/2010 18:13, Robin Berjon a écrit : Hi Cyril, On Jan 12, 2010, at 17:34 , Cyril Concolato wrote: Le 11/01/2010 15:41, Robin Berjon a écrit : Ah, do you have a pointer? I searched for MPEG-U in all the public and member lists yet only this thread shows up. The liaison was sent by the ISO/IEC/JTC1/SC29 secretariat, and since MPEG did not receive any feedback, I checked and was informed that it was mistakenly sent to Tim Berners Lee ! I informed Doug and Mike of that fact, I thought that it would be discussed in the WG. Anyway it doesn't matter anymore since I think the liaison is outdated. Heh! I know it's hard to get any ISO secretariat to do the right thing with liaisons, but the best for liaisons is to send them directly to this list, preferably through a common member (like the equally delightfully named ISO/IEC JTC1/SC34/WG4 recently did). Yes, you're right, the problem is that liaisons usually are not considered as public documents so the secretariat or MPEG members are not allowed to make them public. If avoidable I'd rather not join yet another mailing list just for a few questions, after which I'd have to unsubscribe again. Since you're closely involved with this work, would you mind answering the questions I outlined in my original post? I'm sorry but the only questions in your email were what's happening aroung MPEG-U ? and Can you enlighten us ?. I thought the web page I set up was providing enough information (background, roadmap, spec). Can you be more precise as to what you want to know ? I'm sorry, I realise that my original message isn't entirely clear in terms of what enlightening us covers :). The web page you sent is indeed helpful in describing MPEG-U, but I had other questions. Here is the part that the enlightenment intended to cover: One reason I'm asking is because some of the work items in that document are interesting in a generic manner, and therefore are things that could make their way into WebApp's charter when it comes up for rechartering (which is soon). I don't think that all that's listed there would be of interest to WebApps (e.g. I'd be surprised if the WG cared about integration with BIFS or ISOFF packaging, assuming members even have heard of them), but some topics (inter-widget communication, context management, aggregation) certainly are. Given MPEG's patent policy and inexperience with web technology one can take a fairly good bet that if MPEG-U defines solutions in this space WebApps won't adopt them, thereby leading to fragmentation: something that the document above states it wishes to avoid. So to make the question more explicit: given the stated goal of avoiding fragmentation (with which I strongly agree) in conjunction with the risk inherent in doing work that won't be adopted or that will take place in parallel, are you aware of any plans in the MPEG-U community to avoid fragmentation on topics that WebApps is likely to take up? That's a good question. My personal understanding was that the initial plan was to have MPEG work on specific topics (and until now the items dealt with by MPEG were not in any W3C charter), to liaise with other standardization bodies working in the area to make sure they are aware of the work done in MPEG and then to coordinate with them to harmonize the solution if necessary. So it would be good if the WG could inform MPEG about the evolution of its charter and possibly have a look at the MPEG spec, and comment on it. Anyway, MPEG is meeting next week, I'll raise your questions and try to have MPEG make a formal answer. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: MPEG-U
Hi Robin, Le 11/01/2010 15:41, Robin Berjon a écrit : Hi Cyril, On Jan 7, 2010, at 15:59 , Cyril Concolato wrote: sorry to put you on the spot, but I don't recall this being discussed by WebApps I know that a liaison was sent from MPEG to the W3C early may 2009 and that the WG was informed. Ah, do you have a pointer? I searched for MPEG-U in all the public and member lists yet only this thread shows up. The liaison was sent by the ISO/IEC/JTC1/SC29 secretariat, and since MPEG did not receive any feedback, I checked and was informed that it was mistakenly sent to Tim Berners Lee ! I informed Doug and Mike of that fact, I thought that it would be discussed in the WG. Anyway it doesn't matter anymore since I think the liaison is outdated. Can you give the WG some general ideas about what's happening around MPEG-U? Actually, I had made a web page that describes it and that I wanted to send earlier [1]. You will find there some background information and the current spec in PDF and soon some examples and code. If you have questions about the GPAC implementation of MPEG-U, you can ask me but if you have questions about the MPEG process, you can post them on the general MPEG Systems mailing list[2]. If avoidable I'd rather not join yet another mailing list just for a few questions, after which I'd have to unsubscribe again. Since you're closely involved with this work, would you mind answering the questions I outlined in my original post? I'm sorry but the only questions in your email were what's happening aroung MPEG-U ? and Can you enlighten us ?. I thought the web page I set up was providing enough information (background, roadmap, spec). Can you be more precise as to what you want to know ? Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: MPEG-U
Hi Robin, Le 06/01/2010 17:43, Robin Berjon a écrit : Hi Cyril, sorry to put you on the spot, but I don't recall this being discussed by WebApps I know that a liaison was sent from MPEG to the W3C early may 2009 and that the WG was informed. and you're listed as one of the authors: http://www.chiariglione.org/mpeg/technologies/mpeg-u/mpu-widgets/index.htm Can you give the WG some general ideas about what's happening around MPEG-U? Actually, I had made a web page that describes it and that I wanted to send earlier [1]. You will find there some background information and the current spec in PDF and soon some examples and code. If you have questions about the GPAC implementation of MPEG-U, you can ask me but if you have questions about the MPEG process, you can post them on the general MPEG Systems mailing list[2]. Cyril [1] http://concolato.blog.telecom-paristech.fr/widgets/mpeg-u/ [2] http://lists.uni-klu.ac.at/mailman/listinfo/gen-sys One reason I'm asking is because some of the work items in that document are interesting in a generic manner, and therefore are things that could make their way into WebApp's charter when it comes up for rechartering (which is soon). I don't think that all that's listed there would be of interest to WebApps (e.g. I'd be surprised if the WG cared about integration with BIFS or ISOFF packaging, assuming members even have heard of them), but some topics (inter-widget communication, context management, aggregation) certainly are. Given MPEG's patent policy and inexperience with web technology one can take a fairly good bet that if MPEG-U defines solutions in this space WebApps won't adopt them, thereby leading to fragmentation: something that the document above states it wishes to avoid. Hence my interrogation; can you enlighten us? Thanks! -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] duplicated feature elements ?
Le 05/01/2010 21:13, Marcos Caceres a écrit : On Tue, Jan 5, 2010 at 8:50 PM, Marcos Caceresmarc...@opera.com wrote: On Wed, Dec 16, 2009 at 10:51 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, There is a test in the test suite for duplicated param element with the same name but different value (v9.wgt). But I did not find, a similar test for duplicated feature elements with the same name. Is this allowed or not ? The algorithm in Step 7 does not say. This is allowed. I've added the following note to make that clear (not checked into cvs yet): Note: This specification allows feature elements with the same name and/or value to be declared more than once. Handling of duplicate feature requests is left up to the implementation. I made a mistake above, it should have read: This specification allows feature elements with the same name attribute value to be declared more than once. Handling of duplicate feature requests is left up to the implementation. Fine, thanks. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] PC simplifying some rules (editorial)
Le 05/01/2010 23:29, Marcos Caceres a écrit : On Wed, Dec 9, 2009 at 1:50 PM, Cyril Concolatocyril.concol...@enst.fr wrote: Hi all, I noticed that 9.1.3. Rule for Finding a File Within a Widget Package indicates that the algorithm returns either a file, null, or an error.. This is not exactly true since if it does return an error or null, it always returns a processable file. Ok, clarified this in the spec (that is, returns a processable file instead of just a file) Fine. I suggest changing the introduction as follows The algorithm returns either a processable file, null, or an error. and then doing the following three edits: - Change point 7 in the license element in 9.1.15. Algorithm to Process a Configuration Document to indicate: If file is null or there is an error in 6 then ignore this element I don't agree with this change. The point already says: If file is not a processable file This implicitly means if file is null or in error or anything else. I agree. - Change the similar point for the icon element. As above. I agree. - Simplify Step 9 - Process the Default Icons by collapsing A.A, A.B and A.C into if potential icon is null or in error or already exists, ignore it The above is not precise enough for my liking, but it made sense to collapse it a given that a processable file is always returned... so, I've changed it to: If the potential-icon is a processable file, determined by the media type given in the media type column of the default icons table, and the potential-icon does not already exist in the icons list of the table of configuration defaults, then append the value of potential-icon to the icons list of the table of configuration defaults. It's a somewhat long sentence, but I can live with it... and it doesn't change what was already there. You're right it's a bit long but I'm also fine with it. Also, I was wondering for quite some time why the spec has a strange structure for Rules vs. Steps. Couldn't you put all the Rules into one section 9.1 and all the Steps in 9.2? Yeah, admittedly, it got a little messy wrt what defines a rule and what defines a step... that was me doing crazy literary experiments in the hope of making the spec easier to read and work with... I wanted to write rules like they were reusable functions, and the Steps as if they were independent parts of a program... not sure if I succeeded, but generally I get people saying they like the way I structured the spec... but have also been told it's confusing. So, you are probably correct that what is defined in Step 9 should have been a rule (and hence gone into 9.1). I don't think there is much point now in changing it, however. We should just be trying to squish any outstanding spec bugs (if any) and otherwise let it be... I was not saying that I don't like the separation between steps and rules. It's just the structure of Section 9 that I find weird. It's ok if you don't change the spec now. you can keep it in mind for a 2nd edition or a 1.1 version :) we still have a ton of work to do on updates and view modes, so I just want to call PC done and start oiling the gears to move it to Proposed Rec by the end of the month. Once GPAC and Widgeon are at 100%, we will have 5 conforming implementations which I think it's a pretty awesome achievement and a testament to the implement-ability of the spec. I agree, this proves that the spec and the test suite are both in good shapes. FYI, out of the 166 tests, GPAC fails 7 because of XML/Unicode handling. This will probably be fixed. 1 fails because we don't implement SNIFF. I don't know if we will. 3 fail because we don't maintain tables of supported mime types, encodings or features, at the level of the widget UA. I don't know yet how to fix that. The last failure is related to the handling of invalid feature elements, on which I disagree with the test suite (see next email). So hopefully, I should get close to the 100% in the future. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets/
Re: [widgets] feature: inconsistent behavior ?
Le 05/01/2010 23:54, Marcos Caceres a écrit : On Wed, Dec 16, 2009 at 10:13 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi, The test df.wgt contains a feature without name. In this case, the feature element is ignored and the widget remains valid. The test d4.wgt contains an invalid feature name. In this case, the widget should be considered as invalid. I don't understand that. I understand the rationale that if a feature is required, the UA shall not process the widget. Whether it does or not understand the feature, it doesn't matter. Is it because you foresee evolution in the syntax of feature names, which wouldn't be IRI ? If not, I suggest to make this test pass and ignore the feature element. Sorry, but it was a resolution that all correctly named features are considered required (it's why we had to create the required attribute). I'm against changing this. It's not because all correctly named features are considered required (on which I agree) that invalid feature names must lead to invalid widgets (on which I disagree). I think invalid feature names should be ignored. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] feature: inconsistent behavior ?
Marcos, Le 06/01/2010 10:52, Marcos Caceres a écrit : On Wednesday, January 6, 2010, Cyril Concolatocyril.concol...@enst.fr wrote: Le 05/01/2010 23:54, Marcos Caceres a écrit : On Wed, Dec 16, 2009 at 10:13 AM, Cyril Concolato cyril.concol...@enst.frwrote: Hi, The test df.wgt contains a feature without name. In this case, the feature element is ignored and the widget remains valid. The test d4.wgt contains an invalid feature name. In this case, the widget should be considered as invalid. I don't understand that. I understand the rationale that if a feature is required, the UA shall not process the widget. Whether it does or not understand the feature, it doesn't matter. Is it because you foresee evolution in the syntax of feature names, which wouldn't be IRI ? If not, I suggest to make this test pass and ignore the feature element. Sorry, but it was a resolution that all correctly named features are considered required (it's why we had to create the required attribute). I'm against changing this. It's not because all correctly named features are considered required (on which I agree) that invalid feature names must lead to invalid widgets (on which I disagree). I think invalid feature names should be ignored. But they (the invalid feature) are required by default (required value defaults to true), hence the widget would probably crash or be rendered useless at runtime regardless. Consider: feature name='foo:bar'/ which manifests itself as 'window.theMightyFoo' at runtime, iff the feature is available. The author, having implicitly said in the config doc feature foo:bar must be there for my widget to work will have to now write additional error handling code to check if the feature is available. This would be fine if the author said: feature name='foo:bar' required='false'/ in which case, the author has made an explicit statement that he or she has (hopefully) coded the widget on the premise that the feature may not be there at runtime. I think you misunderstood me. There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: widget named4/name feature name=invalid feature IRI required=true/ /widget I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] PC simplifying some rules (editorial)
Le 06/01/2010 11:22, Scott Wilson a écrit : On 6 Jan 2010, at 08:56, Cyril Concolato wrote: [snip] 1 fails because we don't implement SNIFF. I don't know if we will. [snip] Actually you don't need to implement SNIFF to pass that particular test, as it only requires you do the extension-processing part of the algorithm. Thanks for the info, but I'm not sure I understand. If you take the algorithm: 1. nothing to do 2. content-type = empty 3. extension = empty 4. name = 'fail' 5. Not applicable (not starting with a full stop) 6. Not applicable (no full stop in the name) 7. Not applicable (no full stop in the name) 8. extension is empty so you go to 10. 10. Process the file according to SNIFF. Am I wrong? See, e.g.: https://svn.apache.org/repos/asf/incubator/wookie/trunk/src/org/apache/wookie/util/ContentTypeUtils.java As you can see we've put a TODO for SNIFF but the code as it stands passes the test fine. Your algorithm returns null even if the file is of a supported media type. In this case, it's fine, it gives the right result but if the 'fail' file did not contain garbage data but say real PNG data, your algorithm would give the wrong result. Anyway, thanks. I did not want to give the impression that I passed this test since SNIFF was not implemented but I will probably do something similar to you because I can actually give the right result for this test, which is what's needed for the report. However, the test suite should include one test really checking SNIFF support to see how many implementations do implement it. Cyril PS: In your code I noticed that line: if (filename.startsWith(,) filename.lastIndexOf(.)==0) return null; Are you sure the , shouldn't be a . ? -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] white space handling
Hi Robin, Le 18/12/2009 18:01, Robin Berjon a écrit : On Dec 18, 2009, at 16:36 , Cyril Concolato wrote: Le 18/12/2009 15:58, Robin Berjon a écrit : P+C doesn't tie processors to a particular version of XML, and lists its white space characters accordingly (and defensively). If you're certain that you will only ever get content that comes from a conforming XML 1.0 implementation, then you probably don't need to check for this. I don't read it like that. PC explicitely references XML 1.0 and never mentions 1.1. So I thought the behavior was conformant to 1.0. It's fine if the spec also handles 1.1 but it should be mentioned. Also the rationale for the choices of space characters should also be indicated and the differences between XML 1.0 and XML 1.1 should be present. I beg to differ. I think that we should build specifications that can handle future changes to the stack I'm fine with that. without listing all the versions that are supported. It's not because you cite what you support that you're restricted to that. I think it helps understanding a spec. P+C is built for XML 1.0, and it's great that it has the resilience to handle changes to 1.1 without a hitch — but who knows what XML 4.2 might add? We can't guarantee that it'll work, but we can try (and if it does work, I don't think that we should list it either). I certainly don't think that it's the right place to document potential differences between versions of XML — as your XHTML example shows, that kind of information goes stale. If you're explicitely citing dated version of the spec, since they're cast in stone, I don't see how they can go stale. Furthermore, I didn't say that the differences between XML 1.0 and 1.1 are the rationale for this choice — I was merely indicating that using 1.1 you could get such characters and that P+C's robustness against that was a plus. I wasn't in Marcos's brain when that part was written but my specification exegesis antennae suspect that the listed class of characters corresponds to the Unicode white space character class (and therefore to what Unicode-aware processors would consider white space, notably \s in regular expressions). Well, you know my concern. I want to understand the spec in order to implement it properly. I'm not asking for any new normative statement, nor any change to the existing ones. I would be fine with informative notes explaining the intents of some choices. For example, as you know, I'm implementing an SVG UA and an PC UA, I want to know what's reusable, what's common without doing XML archaeology. Such notes would help me and I suspected it would help others. Nothing more. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets/
Re: [widgets] white space handling
For space characters, why did you add U+000B and U+000C? I think this question is even more important if you note that XHTML 1 indicates that U+000C is an invalid XML char (see http://www.w3.org/TR/xhtml1/#C_15) Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] white space handling
Hi Widget addicts, While reading again through the spec, I'm wondering why there are differences between the PC spec and the XML spec in terms of white space handling. PC defines: * space characters as: U+0020, U+0009, U+000A, U+000B, U+000C, U+000D * Unicode white space characters as: U+0009-U+000D, U+0020, U+0085, U+00A0, U+1680, U+180E, U+2000-U+200A, U+2028, +2029, U+202F, U+205F, U+3000 * control characters as: U+-U+001F, U+007F * forbidden characters as: control characters and U+003C, U+003E, U+003A, U+0022, U+002F, U+005C, U+007C, U+003F, U+002A, U+005E, U+0060, U+007B, U+007D, U+0021. space characters are used in Rule for Getting a Single Attribute Value, Rule for Getting a List of Keywords From an Attribute, Rule for Parsing a Non-negative Integer, algorithm to derive the user agent locales and ZIP handling. Unicode white space characters are used only in Rule for Getting Text Content with Normalized White Space control characters are only used only in forbidden characters and forbidden characters are used only in ZIP processing. XML defines white space as: U+0020, U+0009, U+000A, U+000D Given that, I have the following questions/remarks: - Why do you define control characters, can't you put their code points in forbidden characters? This would simplify the spec and make it more easy to understand. - Could you rename forbidden characters to ZIP forbidden characters? This would clearly indicate in which area they are forbidden and why they are defined. - Why do the definition of PC space characters and Unicode white space charactes differ from the XML white space definition? For Unicode white space characters, I could understand this difference since it's only used in the Rule for Getting Text Content with Normalized White Space which first applies XML parsing, DOM3 textContent behavior and then applies additional PC-defined behavior. But still, I'm wondering: is this difference really needed? If yes, can you add a note explaining the rationale and difference with the basic XML processing. For space characters, why did you add U+000B and U+000C? - Ignoring U+000B and U+000C, the Rule for Getting a Single Attribute Value seems to me to be already defined in XML as Attribute-Value Normalization(http://www.w3.org/TR/xml/#AVNormalize). I could understand that you want a self-contained spec but you should at least indicate that the behavior is the same as the basic XML processing. Best regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] features: default value for required
Hi all, The algorithm for processing the 'required' attribute is unclear. It says: If a required attribute is used, then let required-feature be the result of applying the rule for getting a single attribute value to the required attribute. If required-feature is not a valid boolean value, then let the value of required-feature be the value 'true'. I think it misses the case when the required attribute is not used. According to the 'Authoring Guideline', it should say: If a required attribute is used, then let required-feature be the result of applying the rule for getting a single attribute value to the required attribute. *If the required attribute is not used or *if required-feature is not a valid boolean value, then let the value of required-feature be the value 'true'. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] feature: inconsistent behavior ?
Hi, The test df.wgt contains a feature without name. In this case, the feature element is ignored and the widget remains valid. The test d4.wgt contains an invalid feature name. In this case, the widget should be considered as invalid. I don't understand that. I understand the rationale that if a feature is required, the UA shall not process the widget. Whether it does or not understand the feature, it doesn't matter. Is it because you foresee evolution in the syntax of feature names, which wouldn't be IRI ? If not, I suggest to make this test pass and ignore the feature element. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets
[widgets] duplicated feature elements ?
Hi all, There is a test in the test suite for duplicated param element with the same name but different value (v9.wgt). But I did not find, a similar test for duplicated feature elements with the same name. Is this allowed or not ? The algorithm in Step 7 does not say. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets
Re: [widgets] test suite, the width/height attribute
Hi Marcos, Le 14/12/2009 16:49, Marcos Caceres a écrit : On Fri, Dec 4, 2009 at 5:04 PM, Cyril Concolatocyril.concol...@enst.fr wrote: Dear Widgets-experts, While checking some of the tests, I found some unclear processing with regards to the width and height attribute of widget element. The spec says: If the width attribute is used, then let normalized width be the result of applying the rule for parsing a non-negative integer to the value of the attribute. If the normalized width is not in error and greater than 0, then let widget width be the value of normalized width. If the width attribute is in error, then the user agent must ignore the attribute. It explicitely says greater than 0 which means that 0 should not be allowed, but the test suite says for c9.wgt that the result should be 0. Argh. Right. This seems inconsistent. On top of that, the spec seems to make the distinction between 'null' (when in error) and '0' (not specified). From an implementation point of view, I would prefer two cases: - specified, not in error, greater than 0, width = the specified value - in error or not specified, width = null, empty or 0. Actually, I would prefer 0 since then the attribute can be implemented as an integer not as a string. What do you think ? Given that a number of UAs have implemented support for getting back the value 0, I think we should just say greater than or equal to 0. So: widget width/height= = Error. value remains null. widget width/height= = Error, value remains null. widget width/height=abc returns 0, value is 0. widget width/height=100abc returns 100, value is 100. widget width/height=000100abc returns 100, value is 100. However, I'm open to just saying return 0 upon error. That's what I would prefer. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] test suite: br.wgt
Hi all, In the test suite, the test br.wgt leads to a widget with no valid start file. I think this should be considered an invalid widget because a Widget UA will not be able to display it, the user may see an icon but nothing happening when activating it. WDYT ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets
Re: [widgets] test suite: br.wgt
Hi, Le 15/12/2009 18:00, Marcos Caceres a écrit : Hi Cyril On Tue, Dec 15, 2009 at 4:41 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, In the test suite, the test br.wgt leads to a widget with no valid start file. I think this should be considered an invalid widget because a Widget UA will not be able to display it, the user may see an icon but nothing happening when activating it. WDYT ? Looking at the test description from the test suite: br.wgt (source files) Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget start file must treated by the user agent as an invalid widget. My mistake, I must have misread with one of the above or below example... BTW, maybe you can improve the sentence: Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget must *be* treated by the user agent as an invalid widget. remove 'start file' and add 'be' Cyril So yes, it is required to be treated as invalid? I checked the config.xml and it seem to be ok? : widget xmlns=http://www.w3.org/ns/widgets; namebr/name content/ content src=fail.html/ /widget -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] PC simplifying some rules (editorial)
Hi all, I noticed that 9.1.3. Rule for Finding a File Within a Widget Package indicates that the algorithm returns either a file, null, or an error.. This is not exactly true since if it does return an error or null, it always returns a processable file. I suggest changing the introduction as follows The algorithm returns either a processable file, null, or an error. and then doing the following three edits: - Change point 7 in the license element in 9.1.15. Algorithm to Process a Configuration Document to indicate: If file is null or there is an error in 6 then ignore this element - Change the similar point for the icon element. - Simplify Step 9 - Process the Default Icons by collapsing A.A, A.B and A.C into if potential icon is null or in error or already exists, ignore it Also, I was wondering for quite some time why the spec has a strange structure for Rules vs. Steps. Couldn't you put all the Rules into one section 9.1 and all the Steps in 9.2? Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] test-cases for icons: some possible errors
Scott Wilson a écrit : On 3 Dec 2009, at 17:26, Marcos Caceres wrote: On Sun, Nov 29, 2009 at 6:03 PM, Scott Wilson scott.bradley.wil...@gmail.com mailto:scott.bradley.wil...@gmail.com wrote: Some more potential test case errors and fixes: == bl.wgt ✔ Tests the UA's ability to locate an icon in a locale folder and at the root of the widget. To pass, after processing, the icons list must contain a pointer to locales/en/icon.jpg, and icon.png, which is at the root of the widget. The icons list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list mmm. I'm not sure I understand how that happens? Section 9.1.3. Rule for Finding a File Within a Widget Package, step 5 in the algorithm should be forcing you to find the localized icon first. Please recheck the spec and I can try to clarify where it is confusing in regards to how files are found (i.e., always localized content first, then followed by unlocalized content) Step 9 is as follows: *For* each file name in the default icons table http://dev.w3.org/2006/waf/widgets/#default-icons-table (from top to bottom) that has a media type http://dev.w3.org/2006/waf/widgets/#media-type0 that is supported http://dev.w3.org/2006/waf/widgets/#supported by the user agent: 1. Let potential-icon be the result of applying the rule for finding a file within a widget package http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget-0 to file name. 2. If the following conditions are all |true|, then append the value of potential-icon to the icons http://dev.w3.org/2006/waf/widgets/#icons0 list of the table of configuration defaults http://dev.w3.org/2006/waf/widgets/#table-of-configuration-defaults: 1. The value of potential-icon is a file http://dev.w3.org/2006/waf/widgets/#file. 2. The potential-icon is a processable file http://dev.w3.org/2006/waf/widgets/#processable-file, determined by the media type http://dev.w3.org/2006/waf/widgets/#media-type0 given in the media type column of the default icons table http://dev.w3.org/2006/waf/widgets/#default-icons-table. 3. The potential-icon does not already exist in the icons http://dev.w3.org/2006/waf/widgets/#icons0 list of the table of configuration defaults http://dev.w3.org/2006/waf/widgets/#table-of-configuration-defaults. 3. Move onto the next file name in the default icons table http://dev.w3.org/2006/waf/widgets/#default-icons-table. So, using this algorithm, pass.png would always come before locales/en/pass.jpg E.g For (icon in icon.svg, icon.ico, icon.png, icon.gif, icon.jpg): A: Looked for icon.svg using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.ico using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.png using the rule in 9.1.3. No localized version, so got root icon.png. B: Appended /icon.png C: Next! A: Looked for icon.gif using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.jpg using the rule in 9.1.3. Found locales/en/icon.jpg B: Appended locales/en/icon.jpg C: Done! Icons List = icon.png, locales/en/icon.jpg I agree. The whole point here is that Step 9 applies on top of Step 5. Step 5 handles the priority of a localized resource over non localized resource sith the same name. This is not the case here. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] test-cases for icons: some possible errors
Hi all, Scott Wilson a écrit : Some more potential test case errors and fixes: == bl.wgt ✔ Tests the UA's ability to locate an icon in a locale folder and at the root of the widget. To pass, after processing, the icons list must contain a pointer to locales/en/icon.jpg, and icon.png, which is at the root of the widget. The icons list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list I agree, see my previous mail. == bm.wgt ✔ Tests the UA's ability to deal with custom icon declaration in the config document and matching default icons. To pass, the icons list must contain a pointer to locales/en/icon.jpg and icon.png, which is at the root of the widget. The list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list I agree but for a different reasons. The reason here is that icon.png is added as a result of Step 7 Process the Configuration Document whereas locales/en/icon.jpg is added as a result of Step 9 Process the Default Icons. Since Step 9 happens after Step 7, the JPG icon happens after the PNG. Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: To pass, the icons list must contain a pointer to either locales/en/icon.jpg or icon.png, which is at the root of the widget. If both are listed, the list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] test-cases for icons: some possible errors
Robin, Robin Berjon a écrit : On Dec 9, 2009, at 14:31 , Cyril Concolato wrote: Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: Agreed, I think we should test for what the *first* icon is in the list (the one that's selected). Listing all the others isn't useful, they're never used. I'm not sure the first one is always selected. The order is implied by the default icons table but a UA may decide that it prefers PNG over SVG (e.g. for processing requirements) even if it supports both. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] test suite, the width/height attribute
Dear Widgets-experts, While checking some of the tests, I found some unclear processing with regards to the width and height attribute of widget element. The spec says: If the width attribute is used, then let normalized width be the result of applying the rule for parsing a non-negative integer to the value of the attribute. If the normalized width is not in error and greater than 0, then let widget width be the value of normalized width. If the width attribute is in error, then the user agent must ignore the attribute. It explicitely says greater than 0 which means that 0 should not be allowed, but the test suite says for c9.wgt that the result should be 0. This seems inconsistent. On top of that, the spec seems to make the distinction between 'null' (when in error) and '0' (not specified). From an implementation point of view, I would prefer two cases: - specified, not in error, greater than 0, width = the specified value - in error or not specified, width = null, empty or 0. Actually, I would prefer 0 since then the attribute can be implemented as an integer not as a string. What do you think ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] element-based localization
Hi Marcos, Robin, Marcos Caceres a écrit : On Mon, Nov 30, 2009 at 3:41 PM, Robin Berjon ro...@berjon.com wrote: On Nov 27, 2009, at 20:55 , Marcos Caceres wrote: On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Really? I wouldn't have thought so. There's a difference between you can have xml:lang there and it is meaningful to have xml:lang there (or on its ancestors). You can have xml:lang on widget, but the widget element cannot really be localised (you can't have two, choosing between them depending on locale). It's not a huge difference, but putting localisable: yes on widget would confuse me. Agreed. I agree too, the widget element should stay with localizable: no but with a possible xml:lang attribute. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I think that this is even more confused than the original :) To clarify, I think you need to make the same distinction I made above re can have xml:lang and supports being localised. Otherwise you get sentences like elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, to which I can only reply ebbeh?. How about: The xml:lang attribute can be used on any element in order to indicate which language is used in the content and attribute values of that element. Its value is inherited, such that if an element has an xml:lang attribute, all of its descendants are considered to be in that language as well, unless they specify their own xml:lang attribute. Note that an element can indicate that it is in no specific language by setting xml:lang to the empty string, irrespective of whether any of its ancestors has an xml:lang attribute. Some of the elements in the widgets namespace are defined to be localisable. This means that they will be processed in a specific manner if they have an xml:lang value (directly or through inheritance), as described in detail in Step 7. WDYT? I *really* like it; you never fail to impress Mr Berjon :) ... but the first para should just be a Note: (we don't want to have that in as normative text because it describes behavior specified in the XML spec... hence, I would add as specified in [XML], bla bla bla). The second paragraph can serve as a normative definition to which all localizable via xml:lang link to. Can you live with that? I agree with Robin's text and with your suggestion to have as specified in [XML]. Cyril If you can, I have added the above to the spec. With that, we are ready to go to CR so please give me your consent. -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] test-suite, default xml:lang
Cyril Concolato a écrit : Hi all, I'm trying to understand the difference between two tests: [1] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/000/config.xml [2] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/003/config.xml In [1], the first description element is supposed to be the valid one (it does not have an xml:lang attribute). In [2], the first description element as a dummy xml:lang that's not supposed to match anything. The second description element does not have the xml:lang attribute, but according to the expected result, it should not be the selected one. I don't understand why? Can you explain what the user locale should be in both cases? The test suite document indicates that it should be en. If this is the case, in [1] no description element shall match. Otherwise you probably want to indicate that some tests assumes * like [1] and others en like [2]. Am I wrong? Actually, I found a sentence that I missed in previous readings, which explains the difference between [1] and [2]: In the case whereby the author does not use an xml:lang attribute, and no element of a particular type with xml:lang matches the user agent locales, the user agent will use the first element that is unlocalized content, in document order, that matches the element type being sought. As a clarification can you tell me what would be the name value for the following config documents assuming the user locale is en only (no *) widget xmlns=http://www.w3.org/ns/widgets; name xml:lang=frA/name name xml:lang=krB/name name xml:lang=itC/name /widget My guess would be: widget xmlns=http://www.w3.org/ns/widgets; name xml:lang=frA/name name xml:lang=krB/name nameD/name name xml:lang=itC/name /widget My guess would be: D Am I correct? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] editing problem
Hi Marcos, Reading the rule for identifying the media type of a file in the editor's draft [1], I think there is an editing problem. The first 4 bullets are numbered (1,2,3,4) and rest of the bullets are not which makes the algorithm refer to step 10 and 11 that don't exist. Regards, Cyril [1] http://dev.w3.org/2006/waf/widgets/#rule-for-identifying-the-media-type-of-a0 -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] element-based localization
Hi, I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. Then, many other elements (author, preference, icon, content ...) don't list this attribute and are not localizable but they can inherit the value of this attribute. The rest of the elements may have the attribute specified or inherited and use it for localization. The paragraph explaining this behavior says: If an element is marked as being localizable via xml:lang with the word no, it means that the element is not localizable via element-based localization. In other words, exclusion of an xml:lang on an element indicates that that element is unlocalized content, except in the case whereby a parent element uses xml:lang (this maintains consistency with the behavior of xml:lang as specified in the [XML] specification). Explicitly declaring xml:lang overrides any xml:lang value inherited from a parent element. I think this paragraph (especially the last 2 sentences) are unclear. I would propose that you clarify as follows: As per [XML] specification, the xml:lang attribute can be specified on any element, including in the widget namespace, and the normal behavior for this attribute shall be applied (i.e. inheritance processing, and propagation of the xml:lang attribute on elements on which it is not specified). However, in this specification, the value of the xml:lang attribute (inherited or specified) shall be used for element-based localization only on the elements that indicates Localizable via xml:lang: Yes. I would also propose to remove the definition of the xml:lang attribute such as: xml:lang Authoring Guidelines:It is optional for authors to use the xml:lang attribute with an name element. because even if not written, XML allows specifying this attribute on any element. Finally, I would also create some tests in the test-suite to check that inheritance is applied and used or not depending on the element type.WDYT? Best regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] test-suite, default xml:lang
Hi all, I'm trying to understand the difference between two tests: [1] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/000/config.xml [2] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/003/config.xml In [1], the first description element is supposed to be the valid one (it does not have an xml:lang attribute). In [2], the first description element as a dummy xml:lang that's not supposed to match anything. The second description element does not have the xml:lang attribute, but according to the expected result, it should not be the selected one. I don't understand why? Can you explain what the user locale should be in both cases? The test suite document indicates that it should be en. If this is the case, in [1] no description element shall match. Otherwise you probably want to indicate that some tests assumes * like [1] and others en like [2]. Am I wrong? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] about test d1.wgt
Hi Marcos, Marcos Caceres a écrit : Hi Cyril, On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi, The test d1.wgt is about the src attribute of the icon element. It says that it tests the following assertion: If the src attribute of this icon element is absent, then the user agent must ignore this element. but the config.xml contains an src attribute with an empty value. This seems a bit different to me. Maybe you should modify the spec as follows: If the src attribute of this icon element is absent *or empty*, then the user agent must ignore this element. Well, you get the same result when you actually search for the file , as it won't be found. But I agree, a simple clarification there won't actually hurt or change the ways UAs work at the moment. Also you should make sure the tests are aligned between the icon element and the content element. There does not seem to be such test with the content element. If you make such test, you should also align the spec in the same manner. I'm not sure I understand, can you design the test to show what you mean. I can then add it to the test suite. I meant that there is test like: widget xmlns=http://www.w3.org/ns/widgets; icon src=/ /widget but no test like: widget xmlns=http://www.w3.org/ns/widgets; content src= / /widget Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] About the test suite
Hi Robin, Robin Berjon a écrit : On Nov 14, 2009, at 04:30 , Marcos Caceres wrote: Also, we are working on an implementation of the widget spec but we don't have support for HTML, only SVG. The tests are currently designed with HTML start files. Would it be possible to have alternative versions with SVG start files ? Sure! I'm happy to include that. However, I will need your help to make that happen. If you can commit some time, then we can talk about how we get SVG as a standard part of the test suite. WDYT? That should actually be reasonably trivial. Most of the HTML documents in the test suite are the same green/red/grey documents. It's easy to make the same in SVG, and then replace all the HTML documents with the same hash with their corresponding SVGs, renaming the .html in the config files. That should leave a few to change manually, but nothing horrible. Yes I agree, that should not be difficult, I've already manually created the green/red SVG files. But I was wondering about the order given in the default start files table. For example, if a widget package contains both a index.htm and index.svg, is the UA required to use index.htm ? If this is the case we need to duplicate the tests. If not, we can add the SVG files and use a single test (for most cases). Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] default start file table vs. src attribute
Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
Robin Berjon a écrit : Hi Cyril, On Nov 20, 2009, at 17:58 , Cyril Concolato wrote: While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? I actually like it, it's one less thing that we need to specify (I was unfavourable to making the configuration requires in the first place). I've implemented it and it works nicely. Yes, it's a bit of a performance hit but it's not so bad and you can cache it easily. I agree that it's not a big burden. I think it's more a question of taste. I would prefer putting more in the configuration than less. What do you mean by you can cache it easily ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
Marcos Caceres a écrit : On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a content element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? The content element is not mandatory, so you kinda need the table. Also, it needs to be specified what precedence a user agent gives to loading files, which is the second purpose of the table. The last purpose of the table is to tell a user agent what MIME type to use for each file type, which is also fairly important. As I replied to Robin, I'd rather make it more explicit in the config file. I think it would make it more readable/understandable without requiring to know/hard-code all the default values. It's a question of taste. My suggestion was more to mandate the content element, to mandate a type attribute and to allow nesting them for indicating the precedence or use document order (multiple content elements, like the icon element). Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] about test d1.wgt
Hi, The test d1.wgt is about the src attribute of the icon element. It says that it tests the following assertion: If the src attribute of this icon element is absent, then the user agent must ignore this element. but the config.xml contains an src attribute with an empty value. This seems a bit different to me. Maybe you should modify the spec as follows: If the src attribute of this icon element is absent *or empty*, then the user agent must ignore this element. Also you should make sure the tests are aligned between the icon element and the content element. There does not seem to be such test with the content element. If you make such test, you should also align the spec in the same manner. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] About the test suite
Hi all, I was reviewing the overview of the test suite [1] and also the compatibility matrix document [2]. I had two questions. Why do the names of the tests have to be so cryptic (e.g. ta-RRZxvvTFHx, ta-dxzVDWpaWg, ...)? Could you use meaningful names like default-start-file-01, default-start-file-02, mime-01, mime-02, magic-number-01, ... Also, we are working on an implementation of the widget spec but we don't have support for HTML, only SVG. The tests are currently designed with HTML start files. Would it be possible to have alternative versions with SVG start files ? Regards, Cyril [1] http://dev.w3.org/2006/waf/widgets-api/test-suite/ [2] http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html -- Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] Comments on LCWD #3
Hi Marcos, Marcos Caceres a écrit : Hi Cyril, Thank you for again taking the the time to review the PC spec... comments below. 2009/10/25 Cyril Concolato cyril.concol...@enst.fr: Dear all, I made a review of the current specification [1] and I have some comments. I realize that I'm sending these comments quite late in the process but I couldn't make an earlier review. The purpose of these comments is not to delay the publication of the specification. The purpose is more to understand the rationale behind the technical choices that have been made and to facilitate implementation. Here are my comments: 1. The handling of localization is different between the icon element and the content element. The icon element does allow element-based localization using the xml:lang attribute and it also allows folder based localization, while the content element only allows folder-based localization. Is it an error or can you give the rationale? Removed xml:lang support (we actually did this a while ago, but in the test suite version of the spec - this will be in the new LCWD to be published tomorrow): http://dev.w3.org/2006/waf/widgets/Overview_TSE.html I don't understand what you mean. The discrepancy between the two elements is still there in this version. Is your plan to remove also xml:lang on the icon element and rely on folder-based localization? 2. The use of media types. 2.a The content element defines a type attribute. Why doesn't the icon element do the same? Yes, it probably should. No one requested this feature and [SNIFF] (see spec for link) covers most of the use cases. Yes, I think it should, relying on sniffing does not seem to me to be a good practice. 2.b Why is section 9.1.10 Rule for Identifying the Media Type of a File needed? This seems akward to do type sniffing. Why not using a media type given in the configuration file? Because content's @type is an optional attribute, hence you need sniffing. There is no other way to determine the type. That's exactly my question. Why @type is not mandatory ? 2.c From 7.11.2, it seems that there can be several icon elements (zero or more) differing by their media types (SVG, PNG ...). Why is this not allowed for the content element (zero or one), e.g. HTML, SVG ...? Please explain the use cases you have in mind (this is on the V2 roadmap, btw - but would like to hear what ideas you have). I'm thinking about widget packages which can contain multiple representation of the widgets in different formats (HTML, SVG or proprietary) so that a User Agent which does not support one of the format, e.g. HTML, can use an alternative, e.g. SVG. 3. Unpackaged widgets. Have you envisaged delivery of unpackaged widgets? Is it in the roadmap of the group? If I understand what you mean, this is already supported: Google for Apache Wookie project and Opera Unite. Another interpretation of the above is: http://some.place/widget.wgt!/some/data That is, accessing stuff in a package as as if it was a resource via a URI (like its done with Jar files). I personally don't think this is good use case for widgets. If they are on a server, then they should just be served as resources. Anyway, I'll let you tell us what you mean. I meant that widgets may not be delivered in a package but as separate individual resources. This would imply changes to the current spec because for instance one cannot do localization by checking each locale subfolders but one can use e.g. HTTP headers. For example, have you envisaged registering a media type for the XML configuration file? No, not yet. However, I don't think it's necessary as it can just be served as application/xml and semantics acted upon from interpreting the namespace. I see but I was mentionning it in the context of unpackaged delivery, ie. you need to identify that you're downloading a widget so the mime type could be useful. Best regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] Comments on LCWD #3
Dear all, I made a review of the current specification [1] and I have some comments. I realize that I'm sending these comments quite late in the process but I couldn't make an earlier review. The purpose of these comments is not to delay the publication of the specification. The purpose is more to understand the rationale behind the technical choices that have been made and to facilitate implementation. Here are my comments: 1. The handling of localization is different between the icon element and the content element. The icon element does allow element-based localization using the xml:lang attribute and it also allows folder based localization, while the content element only allows folder-based localization. Is it an error or can you give the rationale? 2. The use of media types. 2.a The content element defines a type attribute. Why doesn't the icon element do the same? 2.b Why is section 9.1.10 Rule for Identifying the Media Type of a File needed? This seems akward to do type sniffing. Why not using a media type given in the configuration file? 2.c From 7.11.2, it seems that there can be several icon elements (zero or more) differing by their media types (SVG, PNG ...). Why is this not allowed for the content element (zero or one), e.g. HTML, SVG ...? 3. Unpackaged widgets. Have you envisaged delivery of unpackaged widgets? Is it in the roadmap of the group? For example, have you envisaged registering a media type for the XML configuration file? Best regards, Cyril [1] Widgets 1.0: Packaging and Configuration, W3C Working Draft 22 October 2009, http://dev.w3.org/2006/waf/widgets/ -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [Widgets] URI Scheme revisited.... again
Hi, It seems to me that Requirement 6 should be split into two requirements: A. A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. B. A conforming specification MUST specify or recommend an addressing scheme to address individual widget instances. For requirement A, I think that, given that the WG specifies a Packaging Format for Widget, it could define as well a Fragment Identifiers syntax for this package. This would have the advantage of separating/hiding the protocol used to retrieved the widget and therefore address the problem of The addressing scheme MUST NOT expose the underlying file system (if any). I think authors are also used to that mechanism and therefore would satisfy The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed. For requirement B, correct me if I'm wrong, but since the exact identifier of a widget instance can only be known at runtime, I don't see how an author can determine it declaratively as a URL before instantiation. So, the URL to the widget instance has to be created at runtime as well. Therefore, I imagine that there could be an API to do the following: querying the available widget instances, then requesting a URL (internal to the User Agent) to a particular widget instance and finally creating the final URL using the previous URL and appending a proper fragment identifier. Therefore it seems to me that a new URI scheme is not necessary. Where is my reasoning wrong? Regards, Cyril Marcos Caceres a écrit : Hi Mark, On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. I see what you mean, the Hoffman draft above reads more like a here is a list of what is wrong with file: rather than a spec. And rfc1738 has been obsoleted. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. We use both relative and absolute URI references, and the base is derived from the i18n model we have introduced. The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). Personally, the solution I keep coming to is something like : widget-uri = http://; widget-engine [: instance-id] / package-name path-absolute [# fragment] Where widget-engine is something akin to using, say, localhost, but uses some arbitrary string that identifies the engine (e.g. theFooEngine). The optional instance-id would be a string that uniquely identifies a widget instance for the purpose of cross-widget communication. However, I can foresee that there may be problems with thieving http's port semantics to uniquely identify an instance (so we leave this out until version 2). The scheme would only support GET requests. For example, http://theFooEngine/barWidget.wgt/index.html#welcome Kind regards, Marcos -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
