[RUS-WG] RUS implementd on relational database

[S.Booth]

I'm new to this list but I'm currently contemplating adding a RUS
service front end to an existing system that uses a relational 
database back-end.

I'd therefore like to make some comments on what looks like a bit of a
long standing issue which is the status of Xpath in the specification.

The most recent documents in the tracker add the ability to specify 
alternate filter dialects which I think is a significant improvement.
However they mandate Xpath-1.0 as a supported dialect which I'm not
sure is a good idea.

   Mandating the use of Xpath-1.0 makes it very difficult
to fully implement the specification using a relational database rather than
a native XML database.

Actually I feel that Xpath-1.0 is not really sufficient anyway. There
does not seem to be any easy way of selecting records by EndTime (e.g.
records run in a specified month) without using features from Xpath-2.0.
I think this is really important as I have over a million accounting
records going back over 6 years in one of my databases and almost all
operations I perform on it select a small subset of this by date range.
Xpath-2.0/Xquery-1.0 have date functions and are fine in this respect.

My own feeling is that rather than mandate any filter dialect it would
be better to allow filters to be specified either by a search-string in a
supported query dialect or alternatively by an XML element that encodes
the minimal set of filters a RUS implementation needs to support.
  As this selection language would only exist as part of the RUS it might
as well be written in XML and be part of the RUS schema rather than creating
an additional specification and custom parsers for a subset of Xpath. 
Provided this additional selection language can be easily mapped to 
Xpath-2.0 predicates it should not add significantly to the difficulty of 
implementing the service on a native XML database.


I think a sensible minimal filtering capability is a list of binary 
comparisons (== != < <= > >=) between 
leaf elements of the UR (identified in the same way as the mandatory
elements) and literal values of the corresponding schema type.
The selected records would be those where all the match conditions
resolve true.
  The update function could be supported by supplying a set of element
assignments along with the selector.

I imagine this would look something like

<FilterList>
<MatchCondition match="lt">
<Target>EndTime</Target>
<Value>2008-08-01 08:00:00Z</Value>
</MatchCondition>
<MatchCondition match="gt">
<Target>EndTime</Target>
<Value>2008-07-01 08:00:00Z</Value>
</MatchCondition>
</FilterList>

The translation of this into predicates is straightforward as is the 
translation into a SQL select statment for elements that have been 
extracted into SQL fields, any remaining match conditions could be 
evaluated by regenerating the XML for the superset of the target records 
returned by the SQL and applying Xpath.
Alternatively we could have a method that queries the permitted target
elements for a selector.


 				Stephen
======================================================================
|epcc| Dr Stephen P Booth             Principal Architect       |epcc|
|epcc| s.booth at epcc.ed.ac.uk          Phone 0131 650 5746       |epcc|
======================================================================