ISSUE-100: Does the RDFa API require a better caching mechanism?

Structured Data query cache

Does the RDFa API require a better caching mechanism?

RDFa 1.1 API
Raised by:
Manu Sporny
Opened on:

Philip Jägenstedt wrote:

All of the mess I originally outlined also applies to DocumentData.getSubjects or getValues. Unless the information can be cached, implementation is not feasible.

Manu Sporny wrote:

Define "cached". Can there be a delay to the cache? To propose an overly simplistic strawman mechanism: the first call to the getSubjects() mechanism forces a parse of the document, but each subsequent call for the next 1000ms uses the cached values?

Would you be okay if the document is re-parsed completely if a new RDFa or Microdata attribute is detected in the inserted DOM elements? What about a .structuredDataDirty flag that notifies the web developer that they should manually re-parse?

I don't see how both Microdata and RDFa would be able to give anyone /live/ updates as both seem to have algorithms that require either part or all of the document to be re-processed. That could kill performance if the DOM is being updated with Microdata/RDFa items 100+ times per second.

We could introduce a delay/throttle to the cache and a callback when new RDFa data is detected. Which one of these strategies seems most likely to address your concerns? Is there another approach that would be better?
Related Actions Items:
No related actions
Related emails:
  1. ISSUE-100 (Structured Data query cache): Does the RDFa API require a better caching mechanism? [RDFa 1.1 API] (from on 2011-07-10)

Related notes:

No additional notes.

Display change log ATOM feed

Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 100.html,v 1.1 2015/03/27 14:12:17 vivien Exp $