XUL Talk:Templates Plan: Difference between revisions
| Line 3: | Line 3: | ||
Separating the query from the conditions would seem to remove efficiency, for example, for a server applying conditions to reduce a scoped data set to a managable size. The current template rules combine query and condition in the condition clause. Perhaps, rather than view this as a short hand for two separate things, let it stay atomic and let new mechanisms emulate the combination. Separating conditions also raises the bar for version 2. Certainly RDF templates could use better condition support, but is it a blocker before deploying a new data-format independent mechanism? Leaving conditions to the query mechanism would isolate this shortcoming in the RDF mechanism, an infrastructure that could be considered separately from making a data format agnostic template builder. Perhaps query-wise, it need never change as it may be superceded by a SPARQL query processor for comprehensive RDF processing. | Separating the query from the conditions would seem to remove efficiency, for example, for a server applying conditions to reduce a scoped data set to a managable size. The current template rules combine query and condition in the condition clause. Perhaps, rather than view this as a short hand for two separate things, let it stay atomic and let new mechanisms emulate the combination. Separating conditions also raises the bar for version 2. Certainly RDF templates could use better condition support, but is it a blocker before deploying a new data-format independent mechanism? Leaving conditions to the query mechanism would isolate this shortcoming in the RDF mechanism, an infrastructure that could be considered separately from making a data format agnostic template builder. Perhaps query-wise, it need never change as it may be superceded by a SPARQL query processor for comprehensive RDF processing. | ||
==== RDF caching and | ==== RDF caching and refresh ==== | ||
Neil pointed out that RDF refresh was implemented last year and it can be called from remote code. However, RDF caching is still an issue. Refresh and caching is a general issue for all "file based" data sources i.e. where they is a load at startup and subsequent queries run off a local cache. | |||
==== RDF templates and RDF loading ==== | ==== RDF templates and RDF loading ==== | ||
A big shortcoming of rdf templates now is that they seem to load data sources synchronously (Neil pointed out to me that this is just an impression - they actually load asynchronously but so fast that they block the browser anyway). A large file certainly blocks the browser. They seem to load the datasource as part of template parsing which doesn't allow a page to register as a builder listener and so catch when the first build of an element completes. As part of version 2, I think loading shouldn't block the browser and there should be an event like "datasourceLoaded" to mark its end. | A big shortcoming of rdf templates now is that they seem to load data sources synchronously (Neil pointed out to me that this is just an impression - they actually load asynchronously but so fast that they block the browser anyway). A large file certainly blocks the browser. They seem to load the datasource as part of template parsing which doesn't allow a page to register as a builder listener and so catch when the first build of an element completes. As part of version 2, I think loading shouldn't block the browser and there should be an event like "datasourceLoaded" to mark its end. | ||
Revision as of 21:58, 5 March 2005
Comments User:Conor325
Separation of query and condition
Separating the query from the conditions would seem to remove efficiency, for example, for a server applying conditions to reduce a scoped data set to a managable size. The current template rules combine query and condition in the condition clause. Perhaps, rather than view this as a short hand for two separate things, let it stay atomic and let new mechanisms emulate the combination. Separating conditions also raises the bar for version 2. Certainly RDF templates could use better condition support, but is it a blocker before deploying a new data-format independent mechanism? Leaving conditions to the query mechanism would isolate this shortcoming in the RDF mechanism, an infrastructure that could be considered separately from making a data format agnostic template builder. Perhaps query-wise, it need never change as it may be superceded by a SPARQL query processor for comprehensive RDF processing.
RDF caching and refresh
Neil pointed out that RDF refresh was implemented last year and it can be called from remote code. However, RDF caching is still an issue. Refresh and caching is a general issue for all "file based" data sources i.e. where they is a load at startup and subsequent queries run off a local cache.
RDF templates and RDF loading
A big shortcoming of rdf templates now is that they seem to load data sources synchronously (Neil pointed out to me that this is just an impression - they actually load asynchronously but so fast that they block the browser anyway). A large file certainly blocks the browser. They seem to load the datasource as part of template parsing which doesn't allow a page to register as a builder listener and so catch when the first build of an element completes. As part of version 2, I think loading shouldn't block the browser and there should be an event like "datasourceLoaded" to mark its end.