W3C home > Mailing lists > Public > public-sml@w3.org > October 2007

Action 118 - Explore implementation of deref() in xPath

From: Valentina Popescu <popescu@ca.ibm.com>
Date: Thu, 4 Oct 2007 12:40:52 -0400
To: public-sml@w3.org
Message-ID: <OFE79EF1AE.0F04808B-ON8525736A.0060B656-8525736A.006108BF@ca.ibm.com>
This note is in response to action 
http://www.w3.org/2005/06/tracker/sml/actions/118 Explore implementation 
of deref() in xPath

This action item has been opened as a follow up on these two bugzilla 

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4656 Restrict XPointer for 
SML implementations on top of relational databases?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4657 Restrict the use of 
deref in sml:field/@xpath for SML implementation built on top of 
relational databases

4656 - It is hard to provide reasonable performance when implementation 
supports SML references pointing to elements other than the root element 
in a target document. 
4657 - 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.

Action item:
Investigate IBM database implementations and verify if an implementation 
of the support described above can result in having the issues identified 
by the above defects. I have reviewed these items with the IBM DB2 Viper 
The missing point we had identified in the first place with 4656 and 4657 
is that it is very hard to prove the contrary as required data is missing.
Both defects acknowledge that an implementation is possible so just 
writing a poc in support of this action item was not sufficient. The end 
goal was to prove that this implementation can provide acceptable 
performance. But there is no clear benchmark defined to identify when the 
implementation meets a performance criteria.
Having these challenges, I have decided to investigate if a Viper 
implementation of the SML functions described above may cause any of the 
issues identified by the two defects.
1. Related to issues identified in 4656 (SML references should be only to 
root document elements):

References to elements within a document are not seen as a major issue for 
Viper. This DB2 implementation is highly competitive and allows various 
types of inter-documents aggregation and correlation. For frequent access, 
the indexing support can be used, which improves even more the tool?s 
execution time and performance.
Viper makes the validation step optional on inserts or updates of xml 
documents so this is not something that can affect the performance on 
database updates. 
2. Related to issues identified in 4657 (Restrict the use of deref in 
sml:field/@xpath for SML implementation built on top of relational 
In theory this can pose a challenging problem to data store 
implementations. With the data we have now (not having a fully implemented 
Viper SML support and not having benchmarks to asses the acceptance 
criteria), the Viper team is confident that this is a challenge that can 
be finalized. This is based on the current high performance implementation 
of the Viper database which puts it on the first place among similar 
products on the market.

Thank you,
Valentina Popescu
IBM Toronto Labs
Phone:  (905)413-2412         (tie-line  969)
Fax: (905) 413-4850
Received on Thursday, 4 October 2007 17:40:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:24:23 UTC