Re: Client side JavaScript i18n API
Hi, we've updated the API proposal (at http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh). We've covered most of the comments related to other APIs, including CommonJS. Could you take another look? (you can leave comments in the document or post them back to this thread) Regards, Nebojsa Ciric On Tue, May 4, 2010 at 8:46 AM, Doug Schepers wrote: > Hi, Robin- > > Robin Berjon wrote (on 4/27/10 12:21 PM): >> >> On Apr 27, 2010, at 18:13 , Phillips, Addison wrote: >>> >>> A project to implement this could go quite fast, I think, but would >>> require agreement by the major browser vendors and a place to do >>> the work. We could do this at W3C, but I think ECMA should be >>> involved from early on. >> >> In general a good place for discussion that involves W3C/TC39 >> coordination is public-script-co...@w3.org. It doesn't have an >> attached group and therefore cannot publish specifications, but >> that's a sausage-making detail that can be handled orthogonally (we >> just need to find a WG that can justify having this in its charter). > > Actually, public-script-coord is associated with the WebApps WG, and was > formed to coordinate between TC39 and the WebApps WG, specifically on Web > IDL issues, but also on other matters of coordination. > > If we do decide to bring this i18n work to W3C (which I think would be a > good idea, though not by necessity in the WebApps WG), we could reuse > public-script-coord, or we could make a new dedicated list. I think the > latter makes more sense, since the i18n folks wouldn't have to drink from > the public-script-coord hose. > > Regards- > -Doug Schepers > W3C Team Contact, SVG and WebApps WGs > > -- Nebojša Ćirić
Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations
On 5/5/2010 1:09 PM, Jeremy Orlow wrote: I'd also worry that if creating the transaction were completely transparent to the user that they might not think to close it either. (I'm mainly thinking about copy-and-paste coders here.) I should have been more clear. That statement goes along with the suggestion to make everything work off of a transaction - object stores, indexes, cursors, etc. They'd have to know about the transaction because they'd have to use it. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations
On Wed, May 5, 2010 at 8:56 PM, Shawn Wilsher wrote: > On 5/5/2010 11:44 AM, Jeremy Orlow wrote: > >> On the other hand, a lot of even the most basic tasks probably should be >> done within a transaction. But if the easiest way to do something is to >> just run it outside of a transaction, I'm guessing a good portion of users >> (including tutorial websites, people giving advice on forums, etc) will >> just >> do it that way. Mandating transactions forces users to be cognizant of >> them. Maybe that's a good thing... >> > To be clear, I'm not disagreeing with that. Mozilla would really love to > reduce the amount of async steps to do anything with a database. Right now, > to get something from an object store, we have three steps: > 1) open database; wait for callback > 2) open object store; wait for callback > 3) get from object store; wait for callback > > Adding the transaction stuff would result in four steps: > 1) open database; wait for callback > 2) open transaction; wait for callback > 3) open object store; wait for callback > 4) get from object store; wait for callback > > Maybe we can get rid of this additional step by giving a transaction to the > consumer immediately available after the call to open, and have a property > on the connection to access the current transaction. But that might > complicate things more too. > I'd also worry that if creating the transaction were completely transparent to the user that they might not think to close it either. (I'm mainly thinking about copy-and-paste coders here.) To be honest, while gross, I don't think 4 steps is _that_ much worse then 3 steps and I still think Pablo's option c is the best one. > This is complicated by the fact that each step blocks similar operations > (can only open a database when another one is not in the process of opening, > same with object stores, etc). This problem goes away with my proposal in > the past [1], but I'm not sure we have consensus on it (or the event based > approach for that matter). > Not sure about Microsoft/Pablo, but you've got my support. I'm definitely convinced that what's currently specced is not adequate. I was leaning towards a callback based interface, but after discussing the pros and cons with several developers and the fact that pretty much all the other new APIs are going with an event based model, it seemed like the best way to go. So I'm actually in the process of landing a patch to switch (my half working implementation in) WebKit over to an event based model. Cheers, > > Shawn > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0961.html
Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations
On 5/5/2010 11:44 AM, Jeremy Orlow wrote: On the other hand, a lot of even the most basic tasks probably should be done within a transaction. But if the easiest way to do something is to just run it outside of a transaction, I'm guessing a good portion of users (including tutorial websites, people giving advice on forums, etc) will just do it that way. Mandating transactions forces users to be cognizant of them. Maybe that's a good thing... To be clear, I'm not disagreeing with that. Mozilla would really love to reduce the amount of async steps to do anything with a database. Right now, to get something from an object store, we have three steps: 1) open database; wait for callback 2) open object store; wait for callback 3) get from object store; wait for callback Adding the transaction stuff would result in four steps: 1) open database; wait for callback 2) open transaction; wait for callback 3) open object store; wait for callback 4) get from object store; wait for callback Maybe we can get rid of this additional step by giving a transaction to the consumer immediately available after the call to open, and have a property on the connection to access the current transaction. But that might complicate things more too. This is complicated by the fact that each step blocks similar operations (can only open a database when another one is not in the process of opening, same with object stores, etc). This problem goes away with my proposal in the past [1], but I'm not sure we have consensus on it (or the event based approach for that matter). Cheers, Shawn [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0961.html smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations
On Wed, May 5, 2010 at 7:02 PM, Shawn Wilsher wrote: > On 5/4/2010 7:17 PM, Pablo Castro wrote: > >> c) require an explicit transaction always, along the lines Nikunj's >> original proposal had it. We would move most methods from database to >> transaction (except a few properties such as version and such, which it may >> still be ok to handle implicitly from the transactions perspective). This >> eliminates this whole problem altogether at the cost of an extra step >> required always. >> > I'm rather loath about adding more asynchronous steps to do even the most > simplest of tasks here. What about only doing this for cursor operations > only? Basically, openCursor would be on the transaction object instead of > on the database object. > On the other hand, a lot of even the most basic tasks probably should be done within a transaction. But if the easiest way to do something is to just run it outside of a transaction, I'm guessing a good portion of users (including tutorial websites, people giving advice on forums, etc) will just do it that way. Mandating transactions forces users to be cognizant of them. Maybe that's a good thing... J
Re: Pre-LC Review Requested: System Information API
Oh, I should add the usual disclaimer: Thisismyopinionandnottheofficialpositionofmozilla.Theregenerallyisn'tsuchathingasanofficialmozillapositiongivenhowdiverseourprojectis.Allopinionsexpressedinthisemailislikelytochangeatthedropofahatespeciallyifyoubribemewithcookies.VoidwhereprohibitedincludingbutnotlimitedtothestateofMaineAlaskaandtheDistrictofColmbia. / Jonas On Wed, May 5, 2010 at 9:52 AM, Jonas Sicking wrote: > First of all, I should note that I don't expect that mozilla will implement > this spec anytime soon, if at all. The user value / privacy risk ratio is > simply too low. > > If we do implement it, we would have to agressively deny all requests until > the user had taken the first step and actively asked to share some > information. Not just passively agreed to share it. > > That said, I'd recommend removing the language about what the receptient of > data information should do with it. I wouldn't want anyone (e.g. spec > writers or implementors) to think that that language actually makes a > difference. > > / Jonas > > On May 5, 2010 8:24 AM, "Robin Berjon" wrote: > > Hi all, > > as part of its work the DAP WG has been developing a System Information API. > The abstract describes it thus: > > """ > This specification defines an API to provide Web applications with access to > various properties of the system which they are running on. Specifically, > properties pertaining to the device hardware are addressed. Examples include > battery status, current network bandwidth. Additionally, some of those > properties offer access to the environment around the device, such as > ambient brightness or atmospheric pressure. > """ > > We are looking at pushing that document into Last Call soon, if all goes > well in two weeks' time. In order to help things go smoothly, if you have an > interest in this simply take a good look at it and send us any feedback that > you may have. > > You can read the current Editor's Draft at: > > http://dev.w3.org/2009/dap/system-info/ > > One specific question that we have is whether maxZoomFactor is enough (with > the assumed minimal factor of 1) or whether there are cases in which zoom > factors below 1 or (Eris forbid) below 0 are ever used (perhaps for wide > angle shots). But of course, all topic are open. > > Thanks a lot for any input! > > -- > Robin Berjon - http://berjon.com/ > > > > >
Re: Seeking implementation data for XBL2
On Wed, May 5, 2010 at 7:31 AM, Tab Atkins Jr. wrote: > On Wed, May 5, 2010 at 5:10 AM, Arthur Barstow wrote: >> Hi André, All, >> >> Below, André asks for XBL2 implementation status. I think the last time this >> was discussed on public-webapps was June 2009 [1] (and a somewhat related >> thread in March 2010 on www-tag [2]). >> >> All - if you have some status information re XBL2 implementations, please do >> share it with us. >> >> -Art Barstow >> >> [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0713.html >> [2] http://lists.w3.org/Archives/Public/www-tag/2009Nov/0036.html > > Last week, Jonas Sicking said he'd be starting his implementation this > week. (He's not on IRC at the moment, so I can't confirm whether he's > actually started yet.) I replied in the newsgroup, but I probably should here too. I expect to resume working on the implementation in a matter of days. However note that it's a big feature so it won't be quick to finish. No timeline exists yet. / Jonas
Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations
On 5/4/2010 7:17 PM, Pablo Castro wrote: c) require an explicit transaction always, along the lines Nikunj's original proposal had it. We would move most methods from database to transaction (except a few properties such as version and such, which it may still be ok to handle implicitly from the transactions perspective). This eliminates this whole problem altogether at the cost of an extra step required always. I'm rather loath about adding more asynchronous steps to do even the most simplest of tasks here. What about only doing this for cursor operations only? Basically, openCursor would be on the transaction object instead of on the database object. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: Pre-LC Review Requested: System Information API
First of all, I should note that I don't expect that mozilla will implement this spec anytime soon, if at all. The user value / privacy risk ratio is simply too low. If we do implement it, we would have to agressively deny all requests until the user had taken the first step and actively asked to share some information. Not just passively agreed to share it. That said, I'd recommend removing the language about what the receptient of data information should do with it. I wouldn't want anyone (e.g. spec writers or implementors) to think that that language actually makes a difference. / Jonas On May 5, 2010 8:24 AM, "Robin Berjon" wrote: Hi all, as part of its work the DAP WG has been developing a System Information API. The abstract describes it thus: """ This specification defines an API to provide Web applications with access to various properties of the system which they are running on. Specifically, properties pertaining to the device hardware are addressed. Examples include battery status, current network bandwidth. Additionally, some of those properties offer access to the environment around the device, such as ambient brightness or atmospheric pressure. """ We are looking at pushing that document into Last Call soon, if all goes well in two weeks' time. In order to help things go smoothly, if you have an interest in this simply take a good look at it and send us any feedback that you may have. You can read the current Editor's Draft at: http://dev.w3.org/2009/dap/system-info/ One specific question that we have is whether maxZoomFactor is enough (with the assumed minimal factor of 1) or whether there are cases in which zoom factors below 1 or (Eris forbid) below 0 are ever used (perhaps for wide angle shots). But of course, all topic are open. Thanks a lot for any input! -- Robin Berjon - http://berjon.com/
Re: Status of Selectors API Level 1 Candidate
On Wed, May 5, 2010 at 4:28 PM, Tab Atkins Jr. wrote: > On Wed, May 5, 2010 at 4:56 AM, Lachlan Hunt wrote: >> I have not been able to test IE9 because I don't have access to Windows >> Vista or 7. I would appreciate it if anyone who has a copy of the last >> public development build, or someone from Microsoft, could report on the >> implementation status in IE9. > > The current developer preview of IE9 fails all of the tests. I didn't > investigate why, and the tools are extremely limited in any case right > now. I can keep you updated when they update the Dev Preview. Something like... just now! ;-) Just tested the 2nd Platform Preview on Windows Vista. Scored: 001: "73.9%: 745 passed, 263 failed" 002: "55.9%: 1222 passed, 966 failed" 003: crashed -- Thomas Broyer /tɔ.ma.bʁwa.je/
Minor DigSig feedback
Hi all, just a minor comment found by build a test case : Section7.1. Common Constraints for Signature Generation and Validation 1. [...] 2. [...] 3. For each ds:Reference element: 1. The URI attribute MUST be a zip relative path from the root of the widget package to the file entry being referenced. This condition should not be applied to same-document references. It only makes sense to 'external' references. Greetings Andreas -- Andreas Kühne phone: +49 177 293 24 97 mailto: kue...@trustable.de Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868 Directors Andreas Kühne Heiko Veit Company UK Company No: 5218868 Registered in England and Wales
Pre-LC Review Requested: System Information API
Hi all, as part of its work the DAP WG has been developing a System Information API. The abstract describes it thus: """ This specification defines an API to provide Web applications with access to various properties of the system which they are running on. Specifically, properties pertaining to the device hardware are addressed. Examples include battery status, current network bandwidth. Additionally, some of those properties offer access to the environment around the device, such as ambient brightness or atmospheric pressure. """ We are looking at pushing that document into Last Call soon, if all goes well in two weeks' time. In order to help things go smoothly, if you have an interest in this simply take a good look at it and send us any feedback that you may have. You can read the current Editor's Draft at: http://dev.w3.org/2009/dap/system-info/ One specific question that we have is whether maxZoomFactor is enough (with the assumed minimal factor of 1) or whether there are cases in which zoom factors below 1 or (Eris forbid) below 0 are ever used (perhaps for wide angle shots). But of course, all topic are open. Thanks a lot for any input! -- Robin Berjon - http://berjon.com/
Re: how to use the access element?
2010/5/5 石梦军 : > Hi: > I don't known how to use widget access request policy, is any examples > for it, thanks. We have a few: http://dev.w3.org/2006/waf/widgets-access/#usage-example -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: DigSig feedback
On May 5, 2010, at 9:40 AM, ext Robin Berjon wrote: Our only other comment on the specification is related to the new requirement for the validator to support C14N11: "A validator MUST support [C14N11] to process a ds:Reference that specifies [C14N11] as a canonicalization method." If we remember the previous discussions, there was a move to [XML- exc-C14N] because of concerns over the level of support for [C14N11]. Making support for this mandatory may cause us some issues in the short term. Can you explain why this requirement has been added? The head of the discussion threads related to the group's decision to move from C14N 1.0 to 1.1 are: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0028.html http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0054.html In those threads you'll find the rationale for making C14N 1.1 mandatory. In practice, I suspect interoperable implementations will need to support both C14N 1.0 and 1.1 (e.g. to assure being able to handle signed widgets based on the July-2009 Candidate and C14N 1.0). -Art Barstow
Re: Seeking implementation data for XBL2
On Wed, May 5, 2010 at 5:10 AM, Arthur Barstow wrote: > Hi André, All, > > Below, André asks for XBL2 implementation status. I think the last time this > was discussed on public-webapps was June 2009 [1] (and a somewhat related > thread in March 2010 on www-tag [2]). > > All - if you have some status information re XBL2 implementations, please do > share it with us. > > -Art Barstow > > [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0713.html > [2] http://lists.w3.org/Archives/Public/www-tag/2009Nov/0036.html Last week, Jonas Sicking said he'd be starting his implementation this week. (He's not on IRC at the moment, so I can't confirm whether he's actually started yet.) ~TJ
Re: Status of Selectors API Level 1 Candidate
On Wed, May 5, 2010 at 4:56 AM, Lachlan Hunt wrote: > I have not been able to test IE9 because I don't have access to Windows > Vista or 7. I would appreciate it if anyone who has a copy of the last > public development build, or someone from Microsoft, could report on the > implementation status in IE9. The current developer preview of IE9 fails all of the tests. I didn't investigate why, and the tools are extremely limited in any case right now. I can keep you updated when they update the Dev Preview. ~TJ
Re: [widgets] WARP default policy
On Wed, May 5, 2010 at 3:59 PM, Scott Wilson wrote: > On 5 May 2010, at 10:40, Robin Berjon wrote: > >> On May 4, 2010, at 19:29 , Scott Wilson wrote: >>> I've just been reading through the WARP spec again, and in particular this >>> stood out: >>> >>> In the default policy, a user agent must deny access to network resources >>> external to the widget by default, whether this access is requested through >>> APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). >>> >>> I'm not sure if this statement is actually helpful here. While it makes >>> sense that WARP defines policies that widen access beyond whatever the UA's >>> default policy may be, is it strictly necessary to define the default >>> policy? >> >> Well, if you think about it a little bit further, is it really necessary to >> have a way of defining a network access policy, and if so is the content >> you're distributing the best place to do so? I personally have a somewhat >> reserved judgement about whether WARP is useful at all. A rather large >> number of people expressed this requirement, so it was delivered, and it's >> quite possible that they were right. But it's also possible that they're not >> which is why I'm happy that it's not part of P+C. >> >> If you noticed this because you're working on it for Wookie, I'm not sure >> that's it's worth the (minimal) effort. WARP makes no sense in a Web context. > > We use it to feed the whitelist our server-side proxy service uses; I've > already implemented it for this admittedly limited purpose in Wookie and it > seems to work fine. But for the most part access policy is dealt with by the > browser security model, which is moving towards making such workarounds > unnecessary in the long run. However, right now we still have a limited UC > for WARP. > Right: so WARP on the Web is a band-aid solution that requires a server-side proxy to retrieve content a browser would not normally be able to access (because of cross-origin restrictions). WARP should not be used where CORS is available (and WARP through a proxy should be used with extreme caution on the Web). -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: [widgets] WARP default policy
On 5 May 2010, at 10:40, Robin Berjon wrote: > On May 4, 2010, at 19:29 , Scott Wilson wrote: >> I've just been reading through the WARP spec again, and in particular this >> stood out: >> >> In the default policy, a user agent must deny access to network resources >> external to the widget by default, whether this access is requested through >> APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). >> >> I'm not sure if this statement is actually helpful here. While it makes >> sense that WARP defines policies that widen access beyond whatever the UA's >> default policy may be, is it strictly necessary to define the default >> policy? > > Well, if you think about it a little bit further, is it really necessary to > have a way of defining a network access policy, and if so is the content > you're distributing the best place to do so? I personally have a somewhat > reserved judgement about whether WARP is useful at all. A rather large number > of people expressed this requirement, so it was delivered, and it's quite > possible that they were right. But it's also possible that they're not which > is why I'm happy that it's not part of P+C. > > If you noticed this because you're working on it for Wookie, I'm not sure > that's it's worth the (minimal) effort. WARP makes no sense in a Web context. We use it to feed the whitelist our server-side proxy service uses; I've already implemented it for this admittedly limited purpose in Wookie and it seems to work fine. But for the most part access policy is dealt with by the browser security model, which is moving towards making such workarounds unnecessary in the long run. However, right now we still have a limited UC for WARP. > > -- > Robin Berjon - http://berjon.com/ > > >
Re: [widgets] WARP default policy
On Wed, May 5, 2010 at 11:40 AM, Robin Berjon wrote: > On May 4, 2010, at 19:29 , Scott Wilson wrote: >> I've just been reading through the WARP spec again, and in particular this >> stood out: >> >> In the default policy, a user agent must deny access to network resources >> external to the widget by default, whether this access is requested through >> APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). >> >> I'm not sure if this statement is actually helpful here. While it makes >> sense that WARP defines policies that widen access beyond whatever the UA's >> default policy may be, is it strictly necessary to define the default policy? > > Well, if you think about it a little bit further, is it really necessary to > have a way of defining a network access policy, and if so is the content > you're distributing the best place to do so? I personally have a somewhat > reserved judgement about whether WARP is useful at all. A rather large number > of people expressed this requirement, so it was delivered, and it's quite > possible that they were right. But it's also possible that they're not which > is why I'm happy that it's not part of P+C. > No, we added it because the HTML-WG refused to define what happens when you run a web page locally. We (the WG) needs this. HTML5 defines a security model, and so should widgets in the absence of the same origin policy. I don't see anyway around this. > > If you noticed this because you're working on it for Wookie, I'm not sure > that's it's worth the (minimal) effort. WARP makes no sense in a Web context. > Exactly, it doesn't because you have CORS, UMP, and our inline friends. But it makes sense in a widget:// context. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
DigSig feedback
Hi all, this is the official Vodafone feedback on the proposed rewriting of DigSig. The spec looks good to us. We don't have any objection to removing the requirement on the signer to order the signature files. Getting the validator to do it instead is fine and is probably preferable. Our only other comment on the specification is related to the new requirement for the validator to support C14N11: "A validator MUST support [C14N11] to process a ds:Reference that specifies [C14N11] as a canonicalization method." If we remember the previous discussions, there was a move to [XML-exc-C14N] because of concerns over the level of support for [C14N11]. Making support for this mandatory may cause us some issues in the short term. Can you explain why this requirement has been added? -- Robin Berjon robineko — hired gun, higher standards http://robineko.com/
Re: Quick review of RDFa DOM API?
Hi Manu,
On May 1, 2010, at 08:03 , Manu Sporny wrote:
> This is a call to see if anyone from this WG can do a quick high-level
> review of the RDFa DOM API. We are planning a FPWD in a week or two and
> would like to see if what we have so far is a good start, makes sense to
> those unfamiliar with RDF/RDFa, and what improvements we should make in
> the coming months to make the API useful for developers. The latest
> (FPWD-ready) document is here:
>
> http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-dom-api-20100429/
Just a very quick review.
- Why would anyone want to capture PlainLiteral values in a specific
encoding? Since the value is provided as a DOMString, it should just be that —
a string, with any original encoding information forgotten. Otherwise, you
should use a binary type to capture the value (maybe a Blob) but I really don't
see why.
- element points to the "first node in the DOM tree that is associated with
this PlainLiteral". I'm not sure what that means.
- language is said to be a "two character language string as defined in
[BCP47]". BCP47 has language codes that have more than two letters. Also, if
the source language is not BCP47 conformant, is it exposed?
- I'm not sure that I fully grasp the full value of the IRI interface. When
TypedLiteral's type field returns an IRI, what is the IRI's element?
- "xsd:DataTime" typo?
- "Any valueOf ();" isn't it "any"? (It's not clear in WebIDL)
- JS doesn't have a DateTime object, just a Date.
- Constructing a triple seems painful:
var trip = new RDFTriple(new IRI("http://foo...";), new
IRI("http://bar...";), new IRI("http://dahut...";));
I can see why from the draft, but shortcuts would help. Or maybe it's a library
thing.
- forEach: you can either define it as receiving just "Function" so that it
gets a function. That's fine, but it doesn't tell you what that function is
called with. The other option is to have it receive a FooCallback object, which
is in turn defined as an interface with a single method that has the signature
you expect, and has [FunctionOnly, NoInterfaceObject].
- any reason why RDFTripleList wouldn't stringify to a list of RDFTriples?
- VERSION. Don't. API versioning doesn't work, in fact it doesn't exist.
- I'm not sure that I understand the value of the "Convenient IRI Mapping".
The intent that I understand is to have:
rdfa.foo.bar # http://foo.com/ns#bar
rdfa.dahut.hunting # http://dahutsgalore.org/vocabularies/hunting
rdfa.dahut.unicorns # http://w3.org/2009/dap
It seems that the proposed solution is that you must first:
rdfa.setMapping("foo", "bar", "http://foo.com/ns#bar";);
rdfa.setMapping("dahut", "hunting",
"http://dahutsgalore.org/vocabularies/hunting";);
rdfa.setMapping("dahut", "unicorns", "http://w3.org/2009/dap";);
What's the added value over:
var myMap = { foo: { bar: "http://foo.com/ns#bar"; },
dahut: { hunting:
"http://dahutsgalore.org/vocabularies/hunting";,
unicorns: "http://w3.org/2009/dap"; }};
?
--
Robin Berjon - http://berjon.com/
Re: Quick review of RDFa DOM API?
Hi Manu, Thanks for your e-mail (and the succinct list of relevant questions). All - can anyone in the WebApps WG/Community commit to a "quick high- level review of the RDFa DOM API" draft? Manu - FYI, we've got a significant number of specs in progress [1] so I don't think you should block on our review. -Art Barstow [1] http://www.w3.org/2008/webapps/wiki/PubStatus On May 1, 2010, at 2:03 AM, ext Manu Sporny wrote: Hi folks, This is a call to see if anyone from this WG can do a quick high-level review of the RDFa DOM API. We are planning a FPWD in a week or two and would like to see if what we have so far is a good start, makes sense to those unfamiliar with RDF/RDFa, and what improvements we should make in the coming months to make the API useful for developers. The latest (FPWD-ready) document is here: http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-dom-api-20100429/ We don't need a thorough technical review - just a quick look through to see if this is an API you could see yourself using, or if you would prefer something else. We're mostly interested in having the following questions answered (answer as few or as many as you'd like): * Is the purpose of the RDFa DOM API clear? * Is it clear how one would extract data about a particular subject? * Is it clear how one could extract data about a certain property? * Does the document makes sense to someone that only has a passing knowledge of RDF and RDFa? * Should we eschew RDF concepts entirely and just return "dumb" associative-arrays? No classes, just associative arrays. * Should we integrate a query language, like SPARQL, or leave that to an add-on library that could use the RDFa DOM API as the basis for that implementation? * Should the "rdfa" library go in the global scope, or on document.rdfa, or something else like document.meta? * Would you rather see the API implemented on document and element objects rather than in an "rdfa" object? Something like element.filterData(); * Is the IRI mapping mechanism a design pattern that developers are comfortable with using? * Should we use more markup/example combinations, or are the current markup-less examples helpful? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarming Goes Open Source http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/
Seeking implementation data for XBL2
Hi André, All, Below, André asks for XBL2 implementation status. I think the last time this was discussed on public-webapps was June 2009 [1] (and a somewhat related thread in March 2010 on www-tag [2]). All - if you have some status information re XBL2 implementations, please do share it with us. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0713.html [2] http://lists.w3.org/Archives/Public/www-tag/2009Nov/0036.html Begin forwarded message: From: ext Jaywalker Date: May 4, 2010 3:41:55 PM EDT To: "dev-tech-...@lists.mozilla.org" Subject: XBL2 Status? (#2) The last status update about XBL 2 has been nearly one year ago, saying the work on it will start soon. Couldn't find any newer information. So how's the implementation of XBL 2 going? Thanks for the info! Cheers. André ___ dev-tech-xbl mailing list dev-tech-...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xbl
Re: Status of Selectors API Level 1 Candidate
+public-webapps, -team-webapps On 2010-05-04 18:23, Arthur Barstow wrote: The Selectors API Candidate says: [[ http://www.w3.org/TR/2009/CR-selectors-api-20091222/ There are several known implementations believed to be complete and interoperable (or on the point of being so) and the WebApps Working Group expects to develop a test suite and use it to show that that these implementations pass early in 2010. The Working Group does not plan to request to advance to Proposed Recommendation prior to 30 April 2010. There is no formal implementation report available at the present time. ]] What's the status and plan for this spec? I believe the test suite is nearly ready [1]. As I mentioned last year, Minefield currently passes 100% of the test suite. However, this has not yet shipped in a release build. I assume it will make it into the next major release after the current 3.6.x branch. The browser used in the BlackBerry 9700 also reportedly passes 100% of the test suite. Opera passes 100% of the baseline test suite. We have failures in the additional tests, which are related to bugs in our Selector implementation. This level of support has shipped in the recent 10.5x builds. WebKit (Safari and Chrome) is still failing 16 of the baseline tests. IE8 is failing 252 of the baseline tests. It exhibits a scripting error in the additional tests that prevents them from running, but I haven't investigated the cause. I have not been able to test IE9 because I don't have access to Windows Vista or 7. I would appreciate it if anyone who has a copy of the last public development build, or someone from Microsoft, could report on the implementation status in IE9. Given the implementations in Opera and Blackberry pass the baseline tests, we technically meet requirements in the proposed exit criteria [2], although I don't see any harm in waiting for the next major Firefox release build. I think only released builds, as opposed to development builds, should be used for meeting the implementation requirement. There was previously a question about whether JavaScript implementations should count, like JQuery. I don't think they should count because they are generally not subject to the same interoperability requirements as a native browser implementation are subject to. i.e. JavaScript implementations only have to work on sites where the author explicitly includes the script, browsers have to work on any site a user visits. I think we should produce some kind of implementation report documenting the results for each browser. P.S. Please feel free to send your response to public-webapps. OK. [1] http://dev.w3.org/2006/webapi/selectors-api-testsuite/ [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
how to use the access element?
Hi: I don't known how to use widget access request policy, is any examples for it, thanks. best my regards!
Re: [widgets] WARP default policy
On May 4, 2010, at 19:29 , Scott Wilson wrote: > I've just been reading through the WARP spec again, and in particular this > stood out: > > In the default policy, a user agent must deny access to network resources > external to the widget by default, whether this access is requested through > APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). > > I'm not sure if this statement is actually helpful here. While it makes sense > that WARP defines policies that widen access beyond whatever the UA's default > policy may be, is it strictly necessary to define the default policy? Well, if you think about it a little bit further, is it really necessary to have a way of defining a network access policy, and if so is the content you're distributing the best place to do so? I personally have a somewhat reserved judgement about whether WARP is useful at all. A rather large number of people expressed this requirement, so it was delivered, and it's quite possible that they were right. But it's also possible that they're not which is why I'm happy that it's not part of P+C. If you noticed this because you're working on it for Wookie, I'm not sure that's it's worth the (minimal) effort. WARP makes no sense in a Web context. -- Robin Berjon - http://berjon.com/
Re: [widgets] API - openURL security considerations
On 4 May 2010, at 14:10, Marcos Caceres wrote: > Right. I have clarified this: > > [[ > A user agent must not navigate the browsing context of a widget > instance through the openURL() method: the concept of navigate is > defined in [HTML5]. This restriction is imposed so an arbitrary web > site cannot gain access to special features, such as those potentially > declared through the configuration document's feature element, that > may be enabled within the widget context. > ]] > >> >> If the method never returns, then the attack you're concerned about is >> probably infeasible (which would be good news); it would also tie widgets >> into a very specific application model that I don't know is desirable. You >> probably want to clarify this. >> > > I kinda get what you are saying here, but I'm having trouble > articulating it in the spec. Can you explain this a bit more or > provide an example. What I thought of was that, if openURL never returned, it's obvious that interaction flooding style UI attacks can't occur. However, you couldn't actually open a URL and continue execution of a widget. That's not desirable. You might want to add a UI consideration around what could usefully happen if there are several pending approvals, though. (E.g., "approve navigating to this harmless link", "approve navigating to that harmless link", "approve sending this super expensive text message.") >> So, to the security considerations: >> >> - if openURL can be executed multiple times, then pretty much everything one >> can say about pop-ups applies. > > By "everything one can say about pop-ups", should I reference > something from the "Web Security Context: User Interface Guidelines"?: > > http://www.w3.org/TR/2010/WD-wsc-ui-20100309/#popups You could. :) > >> - as Adam said, file: URIs deserve some extra thought > > I responded to Adam and CC'd you: > > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0439.html I'll be curious what Adam thinks about making non-support for data, file, and javascript normative. I'd lean toward being in favor of that. >> - it's perhaps worthwhile to spell out to implementers that there are many >> ways to write a URI handler that isn't safe, e.g., assuming that just >> because a scheme has a particular syntax that syntax is actually followed. > > What would be some recommendations for guarding against malformed URIs? So, you have the notion of un-trusted scheme handlers in the document already: > In the case that passing a URL to an un-trusted scheme handler, it is > recommended that a the user agent prompt the user prior passing the URI to a > scheme handler. In particular, this would apply, for example, to sms: and > similar schemes. Perhaps add something like this: "Note that URI syntax depends on the URI scheme. URI handlers therefore cannot rely on user agents to sanitize URI references before they are passed on, and need to be prepared to process arbitrary data securely."
Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations
On Wed, May 5, 2010 at 3:17 AM, Pablo Castro wrote: > The interaction between transactions and objects that allow multiple > operations is giving us trouble. I need to elaborate a little to explain the > problem. > > You can perform operations in IndexedDB with or without an explicitly > started transaction. When no transaction is present, you get an implicit one > that is there for the duration of the operation and is committed and the end > (or rolled-back if an error occurs). > > There are a number of operations in IndexedDB that are a single step. For > example, store.put() occurs either entirely in the current transaction (if > the user started one explicitly) or in an implicit transaction if there > isn't one active at the time the operation starts. The interaction between > the operation and transactions is straightforward in this case. > > On the other hand, other operations in IndexedDB return an object that then > allows multiple operations on it. For example, when you open a cursor over a > store, you can then move to the next row, update a row, delete a row, etc. > The question is, what is the interaction between these operations and > transactions? Are all interactions with a given cursor supposed to happen > within the transaction that was active (implicit or explicit) when the > cursor was opened? Or should each interaction happen in its own transaction > (unless there is a long-lived active transaction, of course)? > > We have a few options: > a) make multi-step objects bound to the transaction that was present when > the object is first created (or an implicit one if none was present). This > requires new APIs to mark cursors and such as "done" so implicit > transactions can commit/abort, and has issues around use of the database > object while a cursor with an implicit transaction is open. > I don't see much point to this option. > b) make each interaction happen in its own transaction (explicit or > implicit). This is quite unusual and means you'll get inconsistent reads > from row to row while scanning unless you wrap cursor/index scans on > transactions. It also probably poses interesting implementation challenges > depending on what you're using as your storage engine. > This is how I read the original spec. > c) require an explicit transaction always, along the lines Nikunj's > original proposal had it. We would move most methods from database to > transaction (except a few properties such as version and such, which it may > still be ok to handle implicitly from the transactions perspective). This > eliminates this whole problem altogether at the cost of an extra step > required always. > > We would prefer to go with option c) and always require explicit > transactions. Thoughts? > I'm happy with c. It is unfortunate that it adds yet another step in the process of doing anything with IndexedDB, but it's probably more likely to yield results the author expected and will simplify things (for UAs and authors).
Re: [widgets] WARP default policy
On Tue, May 4, 2010 at 7:29 PM, Scott Wilson wrote: > I've just been reading through the WARP spec again, and in particular this > stood out: > In the default policy, a user agent must deny access to network > resources external to the widget by default, whether this access is > requested through APIs (e.g. XMLHttpRequest) or through markup > (e.g. iframe, script, img). > I'm not sure if this statement is actually helpful here. While it makes > sense that WARP defines policies that widen access beyond whatever the UA's > default policy may be, is it strictly necessary to define the default > policy? I agree, this is unhelpful in the way it is written. This assumes that the default policy is "about:blank" or "widget:" (and even for those, the default policy is not defined - that is, HTML5, AFAIK, does not define about:blank and widget: does not defined a default policy). That is wrong IMO. Wookie demonstrates that by embedding the widget within a web page the widget's security model will be the one given by the browser. In the case of wookie, CORS makes more sense than WARP. WARP is only really suitable for when the widget is relying on a restrictive security context implied by a given origin (i.e., if origin is "widget://xxx" or other non-Web one, then WARP applies; Else, if origin is from http/https the web (HTML5) security model applies). > For example, this implies that a UA should actively block widgets using > JSONp, CORS, Google's Ajax libraries, CDNs, or even a widget just grabbing > its company's icon off their website in an img tag. Agree. > Now there may be UAs who have a default policy that is this strict, but > requiring this to be the default policy as a conformance requirement for any > WARP implementation seems OTT. Agree. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
