Re: [whatwg] Recursion and loops of Microdata items
On Wed, Jun 29, 2011 at 8:47 AM, Philip Jägenstedt wrote: > Another option would be to let stringification of microdata with itemref > loops throw and exception and fail, similar to what happens when you try to > JSON.stringify a JavaScript object with cyclic references. The exact > approach taken here probably isn't very important, since itemref loops > aren't valid in the first place. > > Note also that other algorithms defined in terms of items and their > properties need to handle loopiness in some way. That's currently RDF, vCard > and iCal conversion. Perhaps something like "loopy item" could be defined > and those algorithms could skip loopy items wherever they occur? Simply > failing is also an acceptable solution, IMO. Throwing an exception when the graph is cyclic would be fine with me. ~TJ
Re: [whatwg] Recursion and loops of Microdata items
On Tue, 28 Jun 2011 16:51:25 +0200, Tomasz Jamroszczak wrote: Dnia 08-06-2011 o 21:51:57 Ian Hickson napisał(a): The goal of itemref="" was just to have a way to handle cases where you have an item's properties scattered around a document. It's caused us more difficulties than helped anything, as far as I can tell. Has anyone implemented it or used it and liked it? I'd be fine with removing it if it's not a lot of trouble... I haven't fixed the algorithm to be written more simply, nor fixed the loops in the JSON stuff, because if we remove itemref="" then those problems just go away. If we want to keep itemref="", though, I will fix them. Any opinions one way or the other? Summary: 1. itemRef attribute must stay. 2. Loops are allowed in our implementation. 3. Infinite recursion prevention should be simple. For sure itemRef attribute of Microdata have to stay, because it makes possible separation of data (the Microdata item properties, the semantics) and view (where contents of those properties should be laid out for browser user). Without itemRef, Microdata becomes "Picodata". After some internal discussion we've came to conclusion that loop removal is possible to implement using DFS Gabow's algorithm of finding strongly connected components of a graph. But it doesn't seems worth the implementation complexity. So instead of Microdata item loop removal, we're more liberal and allow loops. But then, what to do when translating Microdata to other format, such as stringification to JSON in Drag'n'drop? The JSON itself is quite primitive when it comes to stringification loops - it just throws an exception. We thought we'll be more flexible. We'll make stringification "as best as possible", and cutting only the last offending link of a cycle. See http://people.opera.com/tjamroszczak/microdata/microdata-loops.png . Unfortunately it means that items which belong to Microdata item loops sometimes will lose properties, and it depends on from where the cycle was reached (see point A1 and A2 in the image). Another option would be to let stringification of microdata with itemref loops throw and exception and fail, similar to what happens when you try to JSON.stringify a JavaScript object with cyclic references. The exact approach taken here probably isn't very important, since itemref loops aren't valid in the first place. Note also that other algorithms defined in terms of items and their properties need to handle loopiness in some way. That's currently RDF, vCard and iCal conversion. Perhaps something like "loopy item" could be defined and those algorithms could skip loopy items wherever they occur? Simply failing is also an acceptable solution, IMO. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] multiple itemtypes in microdata?
On Tue, 28 Jun 2011 19:53:02 +0200, Ian Hickson wrote: On Tue, 28 Jun 2011, Philip Jägenstedt wrote: On Mon, 27 Jun 2011 07:53:53 +0200, John Giannandrea wrote: > > In the user feedback from the schema.org proposal, which uses > microdata as its syntax, we have seen several use cases that would > seem to require multiple itemtypes per itemscope. > > Currently the microdata spec only allows one itemtype which defines > the meaning of the vocabulary for subsequent itemprops. > > Allowing an arbitrary list of itemtypes would not be desirable because > then a user agent would have to have knowledge of the type > vocabularies in order to parse the page. Nothing needs to be known about the vocabulary in order to handle itemtype currently, at least if by "user agent" you mean browsers and the DOM API. In other words, allowing multiple types wouldn't be a problem here. That depends how multiple types are done. If all the non-URL properties are assumed to be those defined by the first type, then it's fine. But if you want to be able to use terms from either vocabulary, you'd need vocabulary knowledge to be able to preprocess the data, which would be counter to microdata's design goals. (For example, suppose you have types A and B and A defined property 'foo'. You have: ... ... If type "B" later has a property "foo" defined as well, the meaning of existing pages changes, as does the necessary processing for generic processors that just want to tag each item with unambiguous properties (e.g. the vocabulary-agnostic Microdata to RDFa conversion algorithm). (s/RDFa/RDF/) Indeed, multiple types doesn't work at all if you want to mix different types. I was assuming that the use case was to extend types, kind of like http://schema.org/Person/Governor. However, it doesn't work all that well even in that case, since there's no way to know which type is the extension of the other and which properties exist only on the extended type. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] AppCache-related e-mails
On Thu, Jun 9, 2011 at 3:21 AM, Ian Hickson wrote: > If you're not loading the main page from the cache, what does this gain > you that regular HTTP caching doesn't? Suppose the content of the main page change very often (like news site). In this case, you don't want to cache the main page since the users want to see the latest main page, not the cached ones when they open the main page later. However, should the network connectivity is down, the user should be presented with the cached main page. This problem can be solved by having the main page to NOT include the news content, but only a static template. The news content is fetched dynamically through XHR and stored in localStorage. However, this complicates the news site (a major redesign of the website is necessary). It would be far easier if there is an option in the MANIFEST file to NOT CACHE the main page. So that the behavior is exactly like caching, but it is far stronger, since the rest of the resources (css, js, images, etc... are never re-fetched from the network). The current HTTP Caching still checks whether the resources are modified, but in app cache, we can explicitly say that they are not modified unless we change the manifest hash. So, in this case, HTML5 App Cache can help make regular online websites far faster, as well as provide offline access should the network is down (or the server is down). This would make the online news site feels online when it's online and offline when it's offline. I don't think HTTP Cache can serve the content if the network / server is down. If the main page is always cached, then the next time the user visits the main page, it will (almost) always see the STALE content of the main page. Then a split second later, the main page refreshes with the most up-to-date version, which is very annoying to the users. > On Mon, 14 Feb 2011, Felix Halim wrote: >> >> I have a use case where it is preferable that the main page is not >> cached: >> >> Suppose you have a main page that changes based on it's ID: >> >> http://example.com/page.php?id=10 >> >> The appCache will store each main page with different id in separate >> cache, which is undesirable! And we DON'T want to cache the main pages, >> since the content differs significantly (think of it as a forum >> website). > > The idea of the appcache feature is to enable offline usage. If you don't > want it cached, how is it going to work offline? It will work offline when the network or the server is down? In such case, the latest (cached) main page is shown. I wasn't very clear when I say "the main page should not be cached". I was saying, we should still keep the main page cached, but always show the online (non cached) main page if the network and the server are alive. >> The main goal here is NOT to make the page offline, but to cache the >> resources that the page uses (i.e, .js, .css, images, etc...) that are >> very likely to be IMMUTABLE (particularly the jQuery.js and jQueryUI >> css+images that almost every sites uses!). > > Appcache only adds one feature: The ability to work offline. > > Everything else that appcache does is already possible with regular HTTP > caching. > > So if you don't want to work offline, just use regular HTTP caching. HTTP Caching requires server modifications on altering the headers and is a non option for users that have no control on the server side. Also, many servers are mostly mis-configured on how to send the correct headers and some proxies may alter them on its way to the client. It would be great to be able to specify what to CACHE and what not in the MANIFEST in the HTML file no matter what HTTP Caching says! HTML5 App Cache here works as the complement for web-developers that cannot do HTTP Caching. Moreover, some HTTP Caching strategies do requires round-trip to the servers which can be hundred of milliseconds slower! If we specify everything in the manifest file, no such round-trip ever necessary. In fact, we can do even better than that by not fetching the MANIFEST itself by including an (optional) manifest's HASH inside the HTML like: If not specified, then the my.manifest will always be checked for modifications. >> Or i would like to update this file, or any file else, i would like to >> update, on demand. > > Not sure what this means. I think it means that we should be able to selectively update any file in the manifest, rather than blindly updating everything if the manifest's hash changes. The ability to selectively update the cached files is very appealing. If your resources are 5 MB, and you know you only want to update on a small file of 1KB... I believe the way the current App Cache updates everything if the manifest file changes is just too inefficient. You can say it can be no worse than HTTP Caching, but it can be made far better! >> The application cache is very powerful. But it is very disappointing, >> that it is only useful for static pages. With a little improvement to >
