RfC: API portion of JSON-LD 1.0 Algorithms and API LCWD; deadline May 10
Manu, on behalf of the RDF WG, requests WebApps review the API portion of the JSON-LD 1.0 Algorithms and API LCWD specification [LC]. I presume this means Section 11 http://www.w3.org/TR/2013/WD-json-ld-api-20130411/#the-application-programming-interface (Manu, if this isn't correct, please clarify.) Individual WG members are encouraged to provide individual feedback. If anyone in WebApps wants to propose an official WG response, please do so ASAP, in reply to this email so the WG can discuss it. Comments should be sent to public-rdf-comme...@w3.org by May 10. -Thanks, ArtB [LC] http://www.w3.org/TR/2013/WD-json-ld-api-20130411/ Original Message Subject:Last Call: JSON-LD 1.0 and JSON-LD 1.0 Algorithms and API Resent-Date:Wed, 17 Apr 2013 20:34:06 + Resent-From:cha...@w3.org Date: Wed, 17 Apr 2013 16:33:37 -0400 From: ext Manu Sporny mspo...@digitalbazaar.com JSON-LD 1.0 and JSON-LD 1.0 Algorithms and API have been published as Last Call specifications. The Last Call period will end on May 10th, 2013. JSON has proven to be a highly useful object serialization and messaging format. This specification defines JSON-LD, a JSON-based format to serialize Linked Data. The syntax is designed to not disturb already deployed systems running on JSON, but provide a smooth upgrade path from JSON to JSON-LD. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines. The specifications can be found here: JSON-LD 1.0: http://www.w3.org/TR/json-ld/ JSON-LD 1.0 Algorithms and API: http://www.w3.org/TR/json-ld-api/ This is a request that the Internationalization Activity do a review of both specifications. It would also be nice if the Linked Data Platform and the Government Linked Data groups could do a review of both specifications. We ask that the Web Apps Working Group review the API portion of the JSON-LD 1.0 Algorithms and API specification. Finally, if any members of the HTML Working Group would like to review the specification, please do so. -- manu
Re: DOM core changes wrt XML document properties
On 4/17/13 11:53 AM, ext Anne van Kesteren wrote: On Wed, Apr 17, 2013 at 4:29 PM, Henry S. Thompson h...@inf.ed.ac.uk wrote: Is there some survey of usage that helped inform your choice of properties to drop? Are there particular minutes of telcons or f2f meetings where this issue was discussed that you can point us to? I don't think so. Hi Henry, Regarding the process related parts of your question, FYI, WebApps's editing policy is one of Edit First and Review Later, as documented in the WG's work mode wiki http://www.w3.org/2008/webapps/wiki/WorkMode#Editors. -AB
Re: Futures and transactions
On 15/04/13 12:50, Anne van Kesteren wrote: So I guess the current solution is fine as longs as either * No JS libraries will want to implement APIs that uses locks, or * Such libraries are ok with not using the built-in Future API and instead re-implementing the Future API themselves. The problem with exposing this directly is that you can also do bad stuff. What kind of bad stuff? There is nothing that the content will magically be able to do and wouldn't be able to do before. Also, this would force content to write their own Future implementation to workaround this limitation which is I believe the opposite intent of specifying Futures in the DOM specification. Given the IndexedDB use case, it seems to me that adding an optional synchronousFlag parameter to the methods in FutureResolver is worth it. Cheers, -- Mounir
Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so great that people have wanted to use the appcache to solve a larger set of types of applications. So to some extent the appcache has been a victim of its own success. The other week a few of us at mozilla got together to discuss how to fix appcache. I.e. how to come up with a solution for the above mentioned problems. We came to a few conclusions. We still want to try to keep a declarative solution. While the current appcache appears to only work really well for very simple applications, we hope that it is possible to find a declarative format which is simple enough to be understandable and practical, while still supporting a large number of applications. However, we do think that there needs to be a script-driven fallback. A declarative solution
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On 4/18/13 12:19 PM, ext Paul Bakaus wrote: Do you have a list collected somewhere? Hi Paul, FYI, you might be able to scrape some UCs from the related workshop papers http://www.w3.org/2011/web-apps-ws/Papers. Virginie's paper includes a few (security-related) UCs http://www.w3.org/2011/web-apps-ws/papers/Gemalto.pdf. -AB
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On Thu, 18 Apr 2013 19:19:17 +0300, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? We submitted a few (they are not completely fleshed out but they are actual things we do) in the related thread http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0949.html For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? There are also use cases in the discussions of hosted apps in the SysApps WG - they are essentially working on the same problem. cheers Chaals Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so great that people have wanted to use the appcache to solve a larger set of types of applications. So to some extent the appcache has been a victim of its own success. The other week a few of us at mozilla got together to discuss how to fix appcache. I.e. how to come up with a solution for the above mentioned problems. We came to a few
