ISSUE-100 (Structured Data query cache): Does the RDFa API require a better caching mechanism? [RDFa 1.1 API]

ISSUE-100 (Structured Data query cache): Does the RDFa API require a better caching mechanism? [RDFa 1.1 API]

http://www.w3.org/2010/02/rdfa/track/issues/100

Raised by: Manu Sporny
On product: RDFa 1.1 API

In http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0004.html

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?

Received on Sunday, 10 July 2011 22:46:44 UTC