Re: [whatwg] Microdata DOM API issues

[Tab Atkins Jr.]

On Fri, Nov 13, 2009 at 5:14 PM, Philip Jägenstedt  wrote:
> The itemref mechanism allows creating arbitrary graphs of items, rather than
> the tree of items that is the intended microdata model (right?). Even though
> my default reaction to graphs is "oh cool", for microdata when the domain
> model is a graph you should probably just represent it with a level of
> indirection (RDF).
>
> Options:
> 1. patch the algorithms which can go into recursion
> 2. patch
> 
> to first check if an itemref'd property creates a loop before adding it to
> candidates
> 3. ?
>
> I think I prefer 2.

Looping in data-graphs is often useful, so I'm not sure I want to
throw it out generally.  Your statement in the first paragraph I'm
quoting, though, says that you'd rather leave loops to be defined in
the vocabulary itself?  So loops would be done by, frex, itemprop'ing
a link to the other element rather than itemref'ing the other element
directly?

That would probably be fine, and is compatible with a tree-based data
model like JSON.  Vocabs should know when loops are
permissible/desirable for themselves.

~TJ

Re: [whatwg] Microdata DOM API issues

[Philip Jägenstedt]

On Fri, 13 Nov 2009 19:27:39 +0100, Philip Jägenstedt   
wrote:


On Thu, 12 Nov 2009 03:23:54 +0100, Philip Jägenstedt  
 wrote:


Why are the algorithms for extracting RDF gone? All that's left is the  
book example with the equivalent Turtle, but it would be nice if it  
were actually defined how to extract RDF. The same for the JSON stuff,  
was that no good?


D'oh! I've been reading the multipage version and missed that it's on  
another page:


http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html

I'll have to try implementing that and see if there are any more issues.



http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#json

This was easy to implement, but the algorithm isn't guaranteed to  
terminate.



  


This simple input causes the algorithm to recurse as the item references  
itself. I went back to the vCard algorithm and found that it too will fail  
to terminate with this input:


http://microformats.org/profile/hcard";>
  http://microformats.org/profile/hcard";>


vEvent is safe as the algorithm never recurses, but the RDF conversion  
algorithm would hit the same problem.


It's certainly possible to create loops which are less easy to spot:


  
  
  ...
  


Or this:


  

  


The itemref mechanism allows creating arbitrary graphs of items, rather  
than the tree of items that is the intended microdata model (right?). Even  
though my default reaction to graphs is "oh cool", for microdata when the  
domain model is a graph you should probably just represent it with a level  
of indirection (RDF).


Options:
1. patch the algorithms which can go into recursion
2. patch  
  
to first check if an itemref'd property creates a loop before adding it to  
candidates

3. ?

I think I prefer 2.

--
Philip Jägenstedt

Re: [whatwg] Microdata DOM API issues

[Philip Jägenstedt]

On Thu, 12 Nov 2009 03:23:54 +0100, Philip Jägenstedt   
wrote:


Why are the algorithms for extracting RDF gone? All that's left is the  
book example with the equivalent Turtle, but it would be nice if it were  
actually defined how to extract RDF. The same for the JSON stuff, was  
that no good?


D'oh! I've been reading the multipage version and missed that it's on  
another page:


http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html

I'll have to try implementing that and see if there are any more issues.

--
Philip Jägenstedt
Opera Software

Re: [whatwg] AJAX History Concerns

[Justin Lebar]

On Thu, Nov 12, 2009 at 5:43 PM, Ian Hickson  wrote:
> The idea is that the string you would put into the back button or history
> menu is not the same as the string you would put into the title bar or
> bookmarks (i.e. not the same as ).

That doesn't seem too unreasonable, but I think it's strange to set
that title through push/replaceState, since an alternate page title is
orthogonal to the idea of an AJAX page with state objects.  It might
be confusing to expose this alternate title in the document object,
but perhaps we could expose it as a property or setter function
somewhere else.  Then we could persist it properly across forward /
backs within the same document.

> document.title is often used to include things like unread count in a mail
> client or RSS reader. That's orthogonal from the state you would want to
> show in the back button ("Inbox", "Spam folder", "Settings", or whatever).

In this case, it seems like we'd want the bookmark title to use the
pushState title, not document.title (e.g. the bookmark would read
"Inbox", not "Inbox (8)").

-Justin