Re: Is there proposal of accessing metadata of media files?
Hi, Arthur, all. Thank you for pointing some resource and providing description. I understand with regret there isn't APIs which will be fixed or implemented in the near future. Regards. --shumpei On Wed, Oct 7, 2009 at 10:39 PM, Arthur Barstow art.bars...@nokia.com wrote: Hi, WebApps does have a related deliverable in its charter: [[ http://www.w3.org/2008/webapps/charter/#deliverables Metadata Access and Extensible Information for Media (MAXIM) a generic API for accessing metadata embedded in or linked to media files ]] However, as you can see from WebApps' publication status wiki, work on this spec is not active because of related work ongoing by the Media Annotations WG: [[ http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications Media Object (http://dev.w3.org/2006/webapi/MediaObject/publish/) - This spec is not active because it is expected to be replaced by the Media Object API in progress by the Media Annotations WG; see Media Object API Use Cases and Requirements (http://www.w3.org/TR/2009/WD-media-annot-reqs-20090604/) ]] Soohong, Media Annotations WG - would you please provide a short update/status and plans regarding your Media API spec? Also, is this the most recent API document: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html -Regards, Art Barstow Begin forwarded message: From: ext Shumpei Shiraishi shumpei.shirai...@gmail.com Date: October 6, 2009 9:16:25 PM EDT To: public-webapps@w3.org public-webapps@w3.org Subject: Is there proposal of accessing metadata of media files? Archived-At: http://www.w3.org/mid/104ce6580910061816p681237c3ua555e8c5dce9b...@mail.gmail.com Hi, all I'm looking for the API proposal of accessing metadata of media files. For example, I'll want to access metadata of audio files for to get it's title, artists, etc. Or, if I need to get the shooting time of photo, I'll want to get it from JPEG's EXIF header. Is there API proposal which satisfies these case? Thanks. -Shumpei Shiraishi
Re: Widget DigSign: Example of a distributor signature document is buggy
Hopefully further (correct) examples are here: http://dev.w3.org/2006/waf/widgets-digsig/tests/ http://dev.w3.org/2006/waf/widgets-digsig/tests/test-suite-unstable.xml Review is very welcome,
Re: [EventSource] feedback from implementors
Ian Hickson wrote: On Fri, 18 Sep 2009, Per-Erik Brodin wrote: When parsing an event stream, allowing carriage return, carriage return line feed, and line feed to denote line endings introduces unnecessary ambiguity into the spec. For example, the sequence \r\r\n\n could be interpreted as three or four line endings. I've clarified the stream parsing format to define the above strictly as three line endings (not counting the end of the line). That should take care of the ambiguity in stream parsing, but not followd by a U+000D CARRIAGE RETURN (LF) should probably read not followed by a U+000A LINE FEED (LF). Since the event stream format isn't yet widely established, and I don't see any compelling arguments why allowing multiple line endings would be beneficial, I hope that it's not too late to change this. Windows and Unix in particular have different default line endings, so I think we would be making authors' lives unnecessarily complicated if we required a particular kind of line-ending. Yes, Windows and Unix applications and libraries use different default line endings and carriage return line feed and a single line feed is what we currently support. We will update the implementation to also support a single carriage return. Another unclarity regards the onmessage attribute listener. Should that trigger for all events of type MessageEvent or only for events that have the event type set to message? The spec explicitly says that 'onmessage' is an 'event handler' with the 'corresponding event handler event type' 'message'; this unambiguously answers the above question. (You might have to look up the terms 'event handler' and 'event handler event type' in HTML5 to make much sense of this, admittedly.) I'm aware of the definitions of 'event handler' and 'event handler event type' in HTML5. As I've mentioned we did manage to get this right, I'm just trying to think of places where others could misinterpret the spec. Also, when calling close on an event source, the spec doesn't say whether or not an error event should be dispatched, unlike the web socket specification that says explicitly to fire an event. In my opinion, an error event should not be dispatched since you may typically call close from an error event listener in order to cancel a reconnect in the case where the connection is reset, which would then result in a second error event being dispatched. No error event is dispatched, because it doesn't say to dispatch one. Similarly, no 'close' event is dispatched, no 'peanut' event is dispatched, and the disk doesn't get reformatted. :-) I figured the disk doesn't get reformatted because that wouldn't be nice to users, but are you sure about the peanut event? Seriously though, sometimes it could be nice to have a must not ... Maybe it's not motivated here. Maybe it would be useful to have a reconnect/reopen method to enable an application to reestablish the connection from a previously closed event source? This is explicitly not supported, because we don't want people doing this. If the connection ever gets closed, then the site likely has a problem, and we do _not_ want to encourage authors to just try to reconnect, since that is more likely to make the problem worse than anything else. You are right, we don't want clients hammering a site that has a problem. What I had in mind was the problem with intermittent network errors causing the EventSource to close. Now that the spec says that an EventSource should automatically try to reconnect on such errors there is no need for a manual reconnect. Finally, it could be useful to be able to reset the reconnection time to the user agent default value by sending the retry field only and leave out the value similar to how you reset the last event id. What's the use case? Take the stock ticker as an example. When the stock market closes the server logic knows that there won't be any new events for a number of hours and so it can send the corresponding reconnection time and close the connection. If the client is still running by the time the market opens, it will reconnect, and the server can now reset the reconnection time to a time that is convenient for the user agent (which is the user agent default value, unknown to the server). -- Per-Erik Brodin Ericsson Research
Re: Widget DigSign: Example of a distributor signature document is buggy
I think the first document should be re-titled (since it isn't generic to XML Signature 1.1): Widgets 1.0: Test Suite for Widget Signature 1.0 It also seems we have two types of tests: 1. syntactic tests that check the presence and placement of XML material - such as locating the signature in the widget package, syntax correctness, presence of required property elements, and use of Role attribute for author and distributor signatures. 2. Signature value verification when specific algorithms are used for a given input. regards, Frederick Frederick Hirsch Nokia On Oct 8, 2009, at 8:07 AM, ext Kai Hendry wrote: Hopefully further (correct) examples are here: http://dev.w3.org/2006/waf/widgets-digsig/tests/ http://dev.w3.org/2006/waf/widgets-digsig/tests/test-suite- unstable.xml Review is very welcome,
[widgets] Draft minutes for 8 October 2009 Voice Conf
The draft minutes from the October 8 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/10/08-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 15 October 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conf 08 Oct 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0073.html See also: [3]IRC log [3] http://www.w3.org/2009/10/08-wam-irc Attendees Present Art, Frederick, Marcos, Jere, Marcin, Steven, Bryan, AndyB, David, Benoit Regrets Josh, Robin Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]P+C: Issue #88 4. [8]PC: Issue #93: deprecated, grandfathered, and redundant tags should be skipped 5. [9]PC: its:dir 6. [10]PC: Need normative statement of Mandatory vs. Optional attributes? 7. [11]is PC-CC ED ready for FPWD? 8. [12]TWI: status of LC comments? 9. [13]TWI: spec testability 10. [14]TWI: LCWD#2 publication plans 11. [15]WARP: is uri attribute name clear enough? 12. [16]WARP: is semantics too constrained? 13. [17]VM-MF spec 14. [18]Updates spec 15. [19]URI spec: who do we ask to review the 8-Oct-2009 LCWD? 16. [20]Requirements doc 17. [21]AOB * [22]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 8 October 2009 Review and tweak agenda AB: draft agenda submitted Oct 7 ( [23]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/00 73.html ). Any change requests? [23] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0073.html [ No ] Announcements AB: does anyone have any short announcements? ... see member-webapps for TPAC announcements MC: I noticed RIM is supporting the W3C widgets spec AB: yes, I saw that too scribe ACTION: barstow contact RIM and ask them to join WebApps [recorded in [24]http://www.w3.org/2009/10/08-wam-minutes.html#action01] trackbot Created ACTION-412 - Contact RIM and ask them to join WebApps [on Arthur Barstow - due 2009-10-15]. P+C: Issue #88 AB: Issue #88 ( [25]http://www.w3.org/2008/webapps/track/issues/88 ) was Raised several months ago. If we are going to address this, the spec must be changed before the next LCWD is published. ... Marcos raised this in May ... we should record a group's decision on this for v1 [25] http://www.w3.org/2008/webapps/track/issues/88 drogersuk Hi, yes on mute Marcos +q drogersuk Horrendous feedback from someone JK: not much a widget can do because there is no event re locale change ... if there was an event, something could be done ... not clear how prefs are connected ... should be locale independent MC: agree it is a no issue Bryan: agree with what has been said ... thus I say don't do anything drogersuk I agree with Bryan's comment AB: any disagreements with what has been said so far? MC: I agree there is no relationship between locale and prefs AB: my recommendation is we change the state to Closed since we aren't going to do anything about it ... any disagreements with that recommendation? [ None ] RESOLUTION: Issue #88 is closed PC: Issue #93: deprecated, grandfathered, and redundant tags should be skipped AB: Issue #93 ( [26]http://www.w3.org/2008/webapps/track/issues/93 ) was raised by Opera during the CR phase. Has this been fixed in the TSE spec? [26] http://www.w3.org/2008/webapps/track/issues/93 MC: yes I believe this has been addressed AB: your use of believe here makes me feel a bit uncomfortable scribe ACTION: caceres send a status report on Issue #93 [recorded in [27]http://www.w3.org/2009/10/08-wam-minutes.html#action02] trackbot Created ACTION-413 - Send a status report on Issue #93 [on Marcos Caceres - due 2009-10-15]. AB: if you think it is closed, please include a proposal to close it, Marcos MC: OK PC: its:dir AB: the its:dir feature is marked At Risk in CR#1. Going forward the options include: remove before LC#3; remove before CR#2; move it to a new spec; keep it in the spec. What do people think we should do with this feature? MC: I think we should leave the feature and remove the at risk ... that is, make it an optional part of the spec AB: any other comments? MH: I'm OK with making it optional JK: I'm
Re: Accept header setting in XHR
On Tue, 25 Aug 2009 19:06:27 +0200, Peter Michaux petermich...@gmail.com wrote: I am looking at the current Working Draft of the XHR spec at the end of section 4.6.3 http://www.w3.org/TR/XMLHttpRequest/#the-send-method Unless set through setRequestHeader() user agents should set the Accept and Accept-Language headers as well. This doesn't specify what the user agent should/must do in the case where the Accept header is set through setRequestHeader(). In my opinion something like the following would be better. If Accept is set through setRequestHeader(), user agents must not set, append or otherwise modify the Accept header. If the Accept header is not set thorugh setRequestHeader(), user agents should set the Accept header. Same for the Accept-Language header. I think avoiding the word Unless would also be an improvement as it is clearer to just use If. Fixed (in a somewhat different way). Thanks! -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] security issue with XMLHttpRequest API compatibility
On Tue, 14 Apr 2009 14:34:11 +0200, Arthur Barstow art.bars...@nokia.com wrote: On Apr 14, 2009, at 6:33 AM, ext Thomas Roessler wrote: So, to pick up on this discussion again -- I don't think we've had a useful conclusion whether or not the client-side JavaScript code ought to explicitly enable cross-site requests (as Tyler suggests, and as IE implements in XDR) or not. All things considered, any thoughts? I tend to think that when adding new semantics, it generally makes sense to add new syntax to support those semantics and in this case that it would be better to err on the side of caution even if the mechanism chosen isn't particularly friendly to the app developer. Yes, it would be good to get others thoughts on this, particularly those that have implemented CORS. If you still feel this way I suggest you put it on the agenda for TPAC so we can briefly discuss it there. Otherwise I suggest we consider this resolved considering that implementations are shipping. I personally think keeping the API the way it is now is nicer and the security issue seems highly theoretical. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson h...@inf.ed.ac.uk wrote: One point of clarification: my (admittedly imperfect) understanding was that the most important parts of CORS have to be implemented _server_-side for the proposal to achieve its goals. If that's true, browser deployment alone is insufficient. Is that a misunderstanding on my part? As was pointed out elsewhere in this thread it was. I was wondering if the TAG considers this item closed or wishes to know something more, in which case I'd like to hear about it! I'm trying to wrap up email threads and this is one of them. Thanks! Kind regards, PS: The remainder of this thread about redirects and CSRF is being taken care of by updates to both CORS and the Origin header draft Adam is working on. In short Origin will most likely become a space-separated list revealing the entire request chain. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Some comments on charset in the Content-Type header
On Sat, 20 Sep 2008 02:58:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: [...] I realize this discussion was well over a year ago. I imagine Gecko has meanwhile dealt with the compatibility issues so we can probably keep it in the specification if you can confirm that. (And add it to XMLHttpRequest Level 2 where it is not yet included.) Could you please also comment on the text in http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-send-method to see if what it says now regarding the Content-Type header and charset parameter is correct? Something I would like to change is to remove the dependency on document.inputEncoding and simply always encode documents as UTF-8 too. Can we do that? This would be better for off-the-shelf XML parsers on the server which might only be able to deal with UTF-8 and UTF-16. Especially in the cross-origin scenario. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] LC comments from the XForms Working Group
On Tue, 17 Jun 2008 05:24:48 +0200, Boris Zbarsky bzbar...@mit.edu wrote: Anne van Kesteren wrote: It would change the conformance criteria. I'm not sure that's a good idea. Especially since the use case put forward is mostly theoretical. Overall, I'm still not convinced this is a good idea. It doesn't seem necessarily that theoretical to me, for what it's worth. Anne, do you happen to have a more or less complete list of the current dependencies of XHR on Window, buy chance? I think that information would be very helpful in seeing where things stand. To wrap this up, I changed XMLHttpRequest some time ago so it can be used in other contexts as well now. If you reuse it you have to define the XMLHttpRequest origin and XMLHttpRequest base URL. My apologies for being a bit stubborn on this earlier. It was mostly because I was hesitant reworking how everything was put together, but it turned out that had to happen anyway. Hopefully it can now be of use to the Forms WG. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] P+C spec doesn't normatively state whether attributes are required or not
Hi Art, Would the following suffice? [[ Authoring Guidelines: The only mandatory element in a configuration document is the widget element. All other elements and their respective attributes are optional. The following example shows the smallest possible configuration document that a user agent will be able to process. widget xmlns=http://www.w3.org/ns/widgets; / ]] Kind regards, Marcos On Wed, Oct 7, 2009 at 4:30 PM, Marcos Caceres marc...@opera.com wrote: On Wed, Oct 7, 2009 at 4:15 PM, Arthur Barstow art.bars...@nokia.com wrote: On Oct 7, 2009, at 10:11 AM, ext Marcos Caceres wrote: On Wed, Oct 7, 2009 at 3:46 PM, Arthur Barstow art.bars...@nokia.com wrote: On Oct 7, 2009, at 9:25 AM, ext Marcos Caceres wrote: (Apologies up front, the following is going to to seem like a rather dumb and slightly condescending discussion. I honestly do not mean it to be, but its necessary to help me identify where I need to fix the specification. Please bear with me.) LOL! On Wed, Oct 7, 2009 at 2:24 PM, Arthur Barstow art.bars...@nokia.com wrote: Since the schema and Authoring guidelines are both non-normative, the P+C spec is not clear if an element's attributes are required or not. When you say required (passive voice), do you mean: My expectation is the spec will normatively state whether an element's attributes (e.g. widget element has id, version, etc.) are required or not in a configuration document. The spec does not set conformance criteria for configuration documents. Sure it does: [[ http://dev.w3.org/2006/waf/widgets/Overview_TSE.html#conformance There are four classes of products that can claim conformance to this specification: 1. A user agent. 2. A widget package. 3. A configuration document. ]] Touché, changed it to: There is only one class of product that can claim conformance to this specification: a user agent. -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Re: [XHR] Last Call comment on about dependencies
On Wed, 25 Jun 2008 15:47:55 +0200, Steven Pemberton steven.pember...@cwi.nl wrote: Thanks for your reply. (We are assuming that this is not a formal reply from the webapps WG.) I'm not sure if I replied to this already. We meanwhile published a draft and will probably do a formal Last Call later on, but it seemed good to wrap this up. In general I believe we do not have formal replies though the WG is expected to vet the Disposition of Comments and participate in the discussions. In this case however this does not matter anymore. [... about removing the HTML5 dependency ...] Our request is that this dependency be removed (or that the connection be made informative instead of normative) so that all interested constituents can take advantage of this important interface as soon as possible. I don't think this is possible. Feel free to go through the public-webapi mailing list archives to find more detailed discussion on this subject if you feel the above is not sufficient: There seem to be several options: 1. XMLHttpRequest is irrevocably bound to HTML5. If that is the case then there seems to be no reason to develop this spec outside of the HTML5 WG, or indeed for developing as a separate spec. It mostly reuses concepts defined by HTML5. It is not the case that it needs to be a single document to ensure some kind of consistency as you would want with e.g. the HTML5 parser algorithm and script execution. 2. XMLHttpRequest is host neutral, and therefore can be used in different environments. If that is the case, and it would seem preferable since there are several other technologies that are able to use this, then it seems good to make it as widely adoptable as possible. It seems like there are two ways to do this: a. copy the restrictions due to HTML5 into this document, so that it is free-standing b. remove the restrictions due to HTML5, and ensure that they are added to that spec, and let languages that use it specify the necessary restrictions needed to make it work in that environment. I think you can use it in other contexts now by defining what the XMLHttpRequest origin and XMLHttpRequest base URL are. You still need to implement the relevant parts of HTML5 that are referenced to be fully conforming of course. An example of a specification that does this is Web Workers: http://dev.w3.org/html5/workers/#interface-objects-and-constructors There seem to be several technologies in W3C that could use XMLHttpRequest; SMIL and XForms come readily to mind. Would you be able to enumerate what it is in XMLHttpRequest that is so bound to HTML5? It is enumerated in the terminology section basically: http://dev.w3.org/2006/webapi/XMLHttpRequest/#terminology Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] security issue with XMLHttpRequest API compatibility
On Thu, Oct 8, 2009 at 7:55 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 14 Apr 2009 14:34:11 +0200, Arthur Barstow art.bars...@nokia.com wrote: On Apr 14, 2009, at 6:33 AM, ext Thomas Roessler wrote: So, to pick up on this discussion again -- I don't think we've had a useful conclusion whether or not the client-side JavaScript code ought to explicitly enable cross-site requests (as Tyler suggests, and as IE implements in XDR) or not. All things considered, any thoughts? I tend to think that when adding new semantics, it generally makes sense to add new syntax to support those semantics and in this case that it would be better to err on the side of caution even if the mechanism chosen isn't particularly friendly to the app developer. Yes, it would be good to get others thoughts on this, particularly those that have implemented CORS. If you still feel this way I suggest you put it on the agenda for TPAC so we can briefly discuss it there. This is my first TPAC. How does one put something on the agenda? Otherwise I suggest we consider this resolved considering that implementations are shipping. I don't understand this argument seeing as how implementations of XDR are already shipping too. I personally think keeping the API the way it is now is nicer and the security issue seems highly theoretical. As with much of the rest of CORS, newly created vulnerabilities seem theoretical until they are deployed an attacked. By the time they do not seem theoretical, it is too late to do better than patch around problems that should not have been introduced. We've been over this before. -- Anne van Kesteren http://annevankesteren.nl/ -- Cheers, --MarkM
Re: [cors] security issue with XMLHttpRequest API compatibility
On Thu, 08 Oct 2009 17:59:56 +0200, Mark S. Miller erig...@google.com wrote: This is my first TPAC. How does one put something on the agenda? I added it here for you as I suppose you do not have a wiki account: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Agenda_Items Otherwise I suggest we consider this resolved considering that implementations are shipping. I don't understand this argument seeing as how implementations of XDR are already shipping too. My assumption is that sites use conditionals to target one or the other and would break if one or the other would no longer work. Maybe it's not too late yet though, dunno. I personally think keeping the API the way it is now is nicer and the security issue seems highly theoretical. As with much of the rest of CORS, newly created vulnerabilities seem theoretical until they are deployed an attacked. By the time they do not seem theoretical, it is too late to do better than patch around problems that should not have been introduced. We've been over this before. Agreed. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] TAG request concerning CORS Next Step(s)
On Thu, Oct 8, 2009 at 8:06 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson h...@inf.ed.ac.uk wrote: One point of clarification: my (admittedly imperfect) understanding was that the most important parts of CORS have to be implemented _server_-side for the proposal to achieve its goals. If that's true, browser deployment alone is insufficient. Is that a misunderstanding on my part? As was pointed out elsewhere in this thread it was. The core criticism that several of us have raised about CORS has never been addressed -- that it creates further confused deputy problems. Rather than addressing the first order confused deputy problem of CSRF, it merely postpones it one level, creating second order confused deputy problems. See Tyler's example. I was wondering if the TAG considers this item closed or wishes to know something more, in which case I'd like to hear about it! I'm trying to wrap up email threads and this is one of them. Thanks! If the confused deputy problems created by CORS have already been addressed, I'd like to hear about that. Did I miss part of the thread? Kind regards, PS: The remainder of this thread about redirects and CSRF is being taken care of by updates to both CORS and the Origin header draft Adam is working on. In short Origin will most likely become a space-separated list revealing the entire request chain. Please go back and read Origin isn't. The redirect problem Tyler pointed out was merely a symptom of a deeper problem. Tyler was able to identify this symptom because he does not regard the underlying problem as merely theoretical. The Origin list solution is curing the symptom only. -- Anne van Kesteren http://annevankesteren.nl/ -- Cheers, --MarkM
RE: Is there proposal of accessing metadata of media files?
Hello Arthur et al. The scenario that you point out is very interesting and is mentioned in Use Cases and Requirements for Ontology and API for Media Object 1.0 . http://www.w3.org/TR/2009/WD-media-annot-reqs-20090604/#req-r01 We will publish a First Public Working Draft of API for Media Resource 1.0 at the end of next week. However I believe we can have a fruitful discussion on how it could be applied. Say for example that you want to develop an application that plays mp3s in the web browser, and you want to get some metadata without loading the mp3 file? Where should the get-function actually be implemented? Regards Joakim Söderberg co-Chair Media Annotations WG -Original Message- From: public-media-annotation-requ...@w3.org [mailto:public-media-annotation-requ...@w3.org] On Behalf Of Shumpei Shiraishi Sent: den 8 oktober 2009 09:15 To: Arthur Barstow Cc: Soohong Daniel Park; public-webapps; public-media-annotat...@w3.org Subject: Re: Is there proposal of accessing metadata of media files? Hi, Arthur, all. Thank you for pointing some resource and providing description. I understand with regret there isn't APIs which will be fixed or implemented in the near future. Regards. --shumpei On Wed, Oct 7, 2009 at 10:39 PM, Arthur Barstow art.bars...@nokia.com wrote: Hi, WebApps does have a related deliverable in its charter: [[ http://www.w3.org/2008/webapps/charter/#deliverables Metadata Access and Extensible Information for Media (MAXIM) a generic API for accessing metadata embedded in or linked to media files ]] However, as you can see from WebApps' publication status wiki, work on this spec is not active because of related work ongoing by the Media Annotations WG: [[ http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications Media Object (http://dev.w3.org/2006/webapi/MediaObject/publish/) - This spec is not active because it is expected to be replaced by the Media Object API in progress by the Media Annotations WG; see Media Object API Use Cases and Requirements (http://www.w3.org/TR/2009/WD-media-annot-reqs-20090604/) ]] Soohong, Media Annotations WG - would you please provide a short update/status and plans regarding your Media API spec? Also, is this the most recent API document: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1. 0.html -Regards, Art Barstow Begin forwarded message: From: ext Shumpei Shiraishi shumpei.shirai...@gmail.com Date: October 6, 2009 9:16:25 PM EDT To: public-webapps@w3.org public-webapps@w3.org Subject: Is there proposal of accessing metadata of media files? Archived-At: http://www.w3.org/mid/104ce6580910061816p681237c3ua555e8c5dce9b...@m ail.gmail.com Hi, all I'm looking for the API proposal of accessing metadata of media files. For example, I'll want to access metadata of audio files for to get it's title, artists, etc. Or, if I need to get the shooting time of photo, I'll want to get it from JPEG's EXIF header. Is there API proposal which satisfies these case? Thanks. -Shumpei Shiraishi
[cors] unaddressed security concerns
On Thu, 08 Oct 2009 18:07:29 +0200, Mark S. Miller erig...@google.com wrote: The core criticism that several of us have raised about CORS has never been addressed -- that it creates further confused deputy problems. Rather than addressing the first order confused deputy problem of CSRF, it merely postpones it one level, creating second order confused deputy problems. See Tyler's example. I'd appreciate a pointer. I was wondering if the TAG considers this item closed or wishes to know something more, in which case I'd like to hear about it! I'm trying to wrap up email threads and this is one of them. Thanks! If the confused deputy problems created by CORS have already been addressed, I'd like to hear about that. Did I miss part of the thread? PS: The remainder of this thread about redirects and CSRF is being taken care of by updates to both CORS and the Origin header draft Adam is working on. In short Origin will most likely become a space-separated list revealing the entire request chain. Please go back and read Origin isn't. The redirect problem Tyler pointed out was merely a symptom of a deeper problem. Tyler was able to identify this symptom because he does not regard the underlying problem as merely theoretical. The Origin list solution is curing the symptom only. I'm not sure what you are referring to, but I thought all outstanding issues were dealt with to be honest. (Or ended in agreed to disagree.) If there are still problems it would help me if they were made more concrete. confused deputy does not help me much because I don't see the problem you are seeing. -- Anne van Kesteren http://annevankesteren.nl/
Re: File API commens
Leaving some of the questions for arun - wouldn't FileStatus be a better name than FileError, given that it can also contain a success code? Actually, we should probably follow HTMLs lead here and design this like the HTMLMediaElement.error property. So make it only contain error codes. - why would a Euro sign be represented as code 128 in a binary string? (don't tell me because of Windows character encodings :-) Indeed, this looks wrong. In general I think it's a bad idea to describe what any particular character represents, as you really shouldn't think about this in terms of characters. Instead it'd be better to say that U0080 represents 128, and U0081 represents 129, and never mention what a or any other character maps to. - mediaType: can this contain parameters? An RFC link that provides an ABNF would be useful here (for instance, http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7) Good question. I suppose if the OS is able to store parameters for the media type for a file then that's possible. - why is a new URI scheme needed? Can't you just use urn:uuid? I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. Would it need to be urn:somename:uuid though? like urn:fileid:uuid? Also, Anne pointed out that we probably want fragment identifiers to work in whatever URI is returned. Would that be possible if we use 'urn'? If I'm reading rfc2141 right, it seems to say it's undefined. / Jonas
Re: File API commens
Jonas Sicking wrote: ... I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. Would it need to be urn:somename:uuid though? like urn:fileid:uuid? ... What's wrong with urn:uuid, which is defined in RFC 4122 and already cited? Also, Anne pointed out that we probably want fragment identifiers to work in whatever URI is returned. Would that be possible if we use 'urn'? If I'm reading rfc2141 right, it seems to say it's undefined. Fragment identifiers are independent of the URI scheme (http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.5). BR, Julian
Re: File API commens
On Thu, 08 Oct 2009 18:53:32 +0200, Julian Reschke julian.resc...@gmx.de wrote: Jonas Sicking wrote: ... I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. Would it need to be urn:somename:uuid though? like urn:fileid:uuid? ... What's wrong with urn:uuid, which is defined in RFC 4122 and already cited? You need to know what the URL is for in other contexts. It seems nicer if that is explicit from the scheme rather than some additional bit of data that is attached to the uuid. -- Anne van Kesteren http://annevankesteren.nl/
Re: File API commens
On Thu, Oct 8, 2009 at 9:53 AM, Julian Reschke julian.resc...@gmx.de wrote: Jonas Sicking wrote: ... I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. Would it need to be urn:somename:uuid though? like urn:fileid:uuid? ... What's wrong with urn:uuid, which is defined in RFC 4122 and already cited? Ah, now I see what you mean. So the URI would be urn:uuid:uuid for example urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 The other thing that needs to be ok is that the lifetime of the URI working, i.e. the time it actually successfully returns the contents of the File, is limited to the lifetime of the Document the File was created in. I guess you could simply view that as the resource behind the urn changing once the Document goes away. Also, Anne pointed out that we probably want fragment identifiers to work in whatever URI is returned. Would that be possible if we use 'urn'? If I'm reading rfc2141 right, it seems to say it's undefined. Fragment identifiers are independent of the URI scheme (http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.5). Excellent. / Jonas
Re: File API commens
Anne van Kesteren wrote: ... What's wrong with urn:uuid, which is defined in RFC 4122 and already cited? You need to know what the URL is for in other contexts. It seems nicer if that is explicit from the scheme rather than some additional bit of data that is attached to the uuid. Example? Pushing this information into the URI seems to be the wrong thing to me... BR, Julian
[widgets] Patent Advisory Group for Widgets 1.0 Updates spec published Recommendations
The Patent Advisory Group that was formed for the Widgets 1.0 Updates spec has now closed and the PAG recommends the work continue. The PAG's Final Report is: http://www.w3.org/2009/03/widgets-pag/pagreport.html The PAG concluded Apple's patent is considered not essential to the Specification. My expectation, not yet discussed with the WebApps' widgets group, is that we will implement all of the PAG's recommendations, as enumerated in the report: http://www.w3.org/2009/03/widgets-pag/pagreport.html#Recommenda -Regards, Art Barstow
Re: File API commens
On Thu, Oct 8, 2009 at 10:03 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 08 Oct 2009 18:53:32 +0200, Julian Reschke julian.resc...@gmx.de wrote: Jonas Sicking wrote: ... I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. Would it need to be urn:somename:uuid though? like urn:fileid:uuid? ... What's wrong with urn:uuid, which is defined in RFC 4122 and already cited? You need to know what the URL is for in other contexts. It seems nicer if that is explicit from the scheme rather than some additional bit of data that is attached to the uuid. You mean that this would be tricky implementation-wise? Since you need to know that a specific uuid references a File rather than something else? / Jonas
Re: File API commens
Julian Reschke wrote: Hi, here are a few comments after a superficial read of http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html: - wouldn't FileStatus be a better name than FileError, given that it can also contain a success code? I'm in the process of updating the spec. to reflect the event-based model [1]. I agree that we shouldn't mix codes here, and I intend to only have error codes. - why would a Euro sign be represented as code 128 in a binary string? (don't tell me because of Windows character encodings :-) This is a mistake; noted with thanks :) - mediaType: can this contain parameters? An RFC link that provides an ABNF would be useful here (for instance, http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7) I refer to RFC 2046 -- is this insufficient? If so, I'll gladly provide an ABNF. - don't say URL when you mean URI As I update the spec., I'll resist this erratic impulse. - RFC 2234 (ABNF) has been updated multiple times, it's now RFC 5234 Noted with thanks. - why is a new URI scheme needed? Can't you just use urn:uuid? So I originally started off with urn:uuid, but switched to a scheme to make *explicit* the reference to file data (and distinct from file://). My reasoning was that a generic urn wasn't as explicit a reference as a scheme would be; moreover, we were defining a subset of HTTP as responses, so I felt that a scheme was more appropriate here. I'm amenable to changing it back to the simpler urn: form if others disagree with this reasoning. Perhaps making it a urn: has the added advantage of further reducing the possibility of confusion with the legacy file:// (which behaves inconsistently). I'm interested in more feedback about this issue. - the definition of URLs and URIs is in RFC 3986, not RFC 1630. Noted with thanks. BR, Julian -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
One use case is to show a tooltip of the word's definition in your accept-language when you mouse over the word in a page. It needs to 1. convert the mouse position to character offset within a node (by Document.caretRangeFromPoint()http://dev.w3.org/csswg/cssom-view/#the-documentview-interface), and 2. expand the range to 'word' unit. It is useful for users, especially users from east asian countries, to read the word's definition in their own language while browsing the internet. And it is also userful for users to check the word's definition in their own language while composing something, such as email. This is why I am thinking of displaying the word's definition for textarea. Which needs Document.caretRangeFromPoint() returns the textarea node as the range container node, and the offset as the character offset within textarea. But Document.caretRangeFromPoint() is only allowed to return nodes in the actual DOM, that a user would be able to get to by traversing from the root node. textarea node is not part of the DOM. Document.caretRangeFromPoint() cannot return a Range in a textarea since that Range would not be in the DOM. I would like to propose another API in Document which has the same functionality of Document.caretRangeFromPoint() but also works for textarea etc. form control nodes that are not part of the DOM. I do not have a good name in mind for such API yet. Would like to hear what you think. Any comments are appreciated! Thanks, Xiaomei
Re: propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
On 10/8/09 10:07 PM, Xiaomei Ji wrote: One use case is to show a tooltip of the word's definition in your accept-language when you mouse over the word in a page. It needs to 1. convert the mouse position to character offset within a node (by Document.caretRangeFromPoint() http://dev.w3.org/csswg/cssom-view/#the-documentview-interface), and 2. expand the range to 'word' unit. It is useful for users, especially users from east asian countries, to read the word's definition in their own language while browsing the internet. And it is also userful for users to check the word's definition in their own language while composing something, such as email. This is why I am thinking of displaying the word's definition for textarea. Which needs Document.caretRangeFromPoint() returns the textarea node as the range container node, and the offset as the character offset within textarea. But Document.caretRangeFromPoint() is only allowed to return nodes in the actual DOM, that a user would be able to get to by traversing from the root node. textarea node is not part of the DOM. Document.caretRangeFromPoint() cannot return a Range in a textarea since that Range would not be in the DOM. I would like to propose another API in Document which has the same functionality of Document.caretRangeFromPoint() but also works for textarea etc. form control nodes that are not part of the DOM. Do you really want to expose those (native) anonymous DOM nodes to web? What should happen if one tries to append them to normal DOM? Or removes them? Or adds (mutation) event listener to them? I think we need a bit different kind of API for form controls. -Olli I do not have a good name in mind for such API yet. Would like to hear what you think. Any comments are appreciated! Thanks, Xiaomei
Request for Comments: 8-Oct-2009 LCWD of Widgets 1.0: Widget URIs; deadline 10 November
Bcc to: www-...@w3.org and public-pkg-uri-sch...@w3.org On Oct 8 WebApps WG published a Last Call Working Draft of the Widgets 1.0: Widgets URIs spec: http://www.w3.org/TR/2009/WD-widgets-uri-20091008/ The deadline for comments is 10 November and all comments should be sent to public-webapps@w3.org (archived at [1]). -Regards, Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/
Re: File API commens
On Thu, 8 Oct 2009, Jonas Sicking wrote: - why is a new URI scheme needed? Can't you just use urn:uuid? I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. I think we need a new URL scheme because otherwise we're going to end up with really complicated origin rules (e.g. the origin of urn:isbn:0123... is a unique ID, but the origin of urn:uuid:0123... is the special file API origin). Reusing urn:uuid would also mean basically hijacking the urn:uuid semantics in browsers and overriding them with something else, such that, e.g., nobody could reuse this scheme in other contexts if there was any risk of the context coming into contact with brosers. And of course there's the implementation cost; APIs generally make it much easier to implement a new scheme than to implement part of the space created by the urn: scheme. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File API commens
On Thu, Oct 8, 2009 at 7:10 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 8 Oct 2009, Jonas Sicking wrote: - why is a new URI scheme needed? Can't you just use urn:uuid? I think we'd really like to avoid creating a new scheme if we could reuse an existing one. I know Arun was looking for an existing scheme, but not sure if he looked at the 'urn' scheme. I think we need a new URL scheme because otherwise we're going to end up with really complicated origin rules (e.g. the origin of urn:isbn:0123... is a unique ID, but the origin of urn:uuid:0123... is the special file API origin). Reusing urn:uuid would also mean basically hijacking the urn:uuid semantics in browsers and overriding them with something else, such that, e.g., nobody could reuse this scheme in other contexts if there was any risk of the context coming into contact with brosers. Whatever scheme we're using for this feature we'll end up with a somewhat messy origin situation. The origin will always have to be on a per-uri bases, and can't be deduced from the uri alone. And of course there's the implementation cost; APIs generally make it much easier to implement a new scheme than to implement part of the space created by the urn: scheme. This seems inherit to the urn scheme. I.e. anyone that implements it will have to make it pluggable on the urn-namespace level. And anyone implementing the uuid namespace will likely have to make it pluggable on a per-uuid level. So at first glance neither of these seem like a problem in Firefox. However this might be especially easy in Firefox since Gecko has its own network library. I'd be interested to get feedback from other UAs. / Jonas
