On Tue, 28 Jun 2011 16:51:25 +0200, Tomasz Jamroszczak <t...@opera.com>
wrote:
Dnia 08-06-2011 o 21:51:57 Ian Hickson <i...@hixie.ch> 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
