[w3c/IndexedDB] Allowing JSONPath, querySelector or other such schemes to index data at arbitrarily nested depths (#211)

With the introduction of service workers and persistent storage along with IndexedDB, the promise of querying documents offline has improved considerably.

Given the natural fit of HTML with the browser, XML/XPath would have been a flexible approach* for a client-side database which could handle *document-centric* as well as *data-centric* object stores.

However, since that boat has sailed with the move to JSON/Structured data, one might at least hope to have HTML documents represented as JSON (e.g., via JsonML or as in my own project, Jamilih), index them, and then use keys or key ranges against the indexes (or, alternatively, allow cloning of DOM objects or indexing within strings in an HTML-aware manner).

However, the native index key path types, such as absolute paths (as via dot-separated identifiers), assume more of a data-centric approach as documents do not typically follow any kind of rigid structure (and even when it is possible, reliance on such is typically fragile).

For example, in sophisticated texts (ranging from those simple documents leveraging Microformats to classical texts richly encoded via Text Encoding Initiative (TEI) XML), one may wish to use descendant selectors, e.g., to find all sentences at various depths within a document marked up as ironic, counting unique closings or words marked as foreign, and any other text analysis operations that do not assume a rigid structure.

Besides such specialized (though not wholly obscure) uses which are not well met currently by IndexedDB, the case for being able to rapidly query against, e.g., `class` and `data-*` attributes, etc. across a set of HTML documents is manifestly useful to the many web applications which rely on `querySelector` and the like. With HTML-escaping, full text indexing might also be implemented as a subset of this scheme (assuming a means to query text nodes were provided, a means not present with CSS selectors).

Might the browsers be willing to address such a fuller range of use cases for indexing data at arbitrarily nested depths than is currently supported?


\* XML databases and the frequent use of XPath (if not XQuery) providing for getting at arbitrary locations within a document, with the current relative advantage over IndexedDB of being able to use native APIs to query less predictably structured document-centric stores as well as data-centric stores.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/211