4657 2007-06-17 18:18:43 +0000 Restrict the use of deref in sml:field/@xpath for SML implementation built on top of relational databases 2007-11-29 19:27:14 +0000 1 1 1 Unclassified SML Core unspecified PC All RESOLVED WONTFIX P1 normal LC 1 pratul.dublish kumarp bassamt public-sml oldest_to_newest 15450 0 pratul.dublish 2007-06-17 18:18:43 +0000 Implementation of SML identity constraints that use the smlfn:deref() function in sml:field/@xpath expressions is challenging for persistent SML stores built on top of relational database systems. The standards body to which SML gets submitted should investigate this and, if needed, explore options to ease the implementation burden for persistent SML stores using relational databases. 16168 1 kumarp 2007-08-16 19:36:54 +0000 *** Bug 4827 has been marked as a duplicate of this bug. *** 16297 2 popescu 2007-08-28 13:23:25 +0000 per f2f decision, moving defect to LC 17006 3 kumarp 2007-10-03 06:04:07 +0000 Proposal: Disallow the use of deref in sml:field/@xpath for SML implementation built on top of relational databases. Reasons: [1] The deref() calls can be nested to any level in the selector or field. Consider the following selector xpath. deref(deref(deref(a)/b)/c)/d/e To evaluate this identity constraint graph, we need to perform a 3 level recursion using a recursive CTE as the first step. Assuming a 10 ref fan-out at each level, it gives us 1000 nodes at the leaf level. This can be done in a relatively straightforward way using a single CTE call. For each of the documents in the target document set thus obtained, we need to apply the xpath ‘/d/e’ to get the target node set. Suppose we have to further evaluate a ‘field’ xpath such as the one shown below. deref(f)/g Here, for each node in the target node set, we need to make a CTE call. Remember that the deref() can be nested to any level. To make matters worse, we may have a case where there are 2 (or more) field xpaths. One without deref() and one with a single deref() (and one with 2 level deref() and so on...). This requires us to combine the result set of the first CTE with that of each of the further CTEs. This is an extremely inefficient operation to perform in a large store. If we can simply shift the ‘deref(f)’ into the selector xpath (for example, deref(deref(deref(deref(a)/b)/c)/d/e)/f)/g) then we can compute the same result set in just one CTE. There is a huge difference in the performance in the 2 cases. [2] Allowing deref() only in the selector support almost all practical cases. [3] If we decide to add this support later it will be a non-breaking change. On the other hand, if we allow deref() in field now and decide to remove that support in later versions of SML, it will be a breaking change. Breaking changes are nearly impossible to make once a standard is adopted. 17166 4 popescu 2007-10-12 21:31:06 +0000 Attached is the result of investigating this issue as required by action http://www.w3.org/2005/06/tracker/sml/actions/118 http://lists.w3.org/Archives/Public/public-sml/2007Oct/0048.html