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

Structured Data query cache

Does the RDFa API require a better caching mechanism?

State:

POSTPONED

Product:

RDFa 1.1 API

Raised by:

Manu Sporny

Opened on:

2011-07-10

Description:

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?

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 sysbot+tracker@w3.org on 2011-07-10)

Related notes:

No additional notes.

Display change log