[RUS-WG] RUS implementd on relational database

[S.Booth]

On Thu, 14 Aug 2008, Xiaoyu Chen wrote:

> /urf:UsageRecord[urf:StartTime>'2008-08-01T00:00:00Z'][urf:EndTime<'2008-08-31T59:59:59Z']
> However evaluation of XPath return null. I presume the reason is the
> XPath engine (of JDK 5) only returns the value of "urf:StartTime"
> and "urf:EndTime" as String and evaluate by comapring to specified
> values.

My reading of the Xpath-1.0 specification is that relational operators
are only valid for numeric values to xpath will attempt to convert
strings to number values (generating NaN in the above
case). Interestingly enough if Xpath compared strings by lexical
ordering the above example would have worked but thats not the way
Xpath-1.0 is defined.


> However XPath 2.0 is more features with additional functional calls
> (for datatime dataype for example). However, for usage records
> persistent in realational database, XPath does not do any good for
> RUS operations.  In our implementation (GRUS and WLCG-RUS) we
> developed a lightweigh XPath2HQL (Hibernate Query Language, which is
> SQL-like but object-oriented) tool. Rather than providing
> general-purpose transformation between XPath and HQL, the tool has a
> set of constrainted rules, such as not supporting XPath function
> calls. We also use Hiberante API for access to hetergoenous
> relational database. A high level abstract, the Data Access Object
> layer, cusotmer implementations can be developed to support XML:DB,
> file system, etc.

I was considering something similar. The obvious problem is that tools
might assume full Xpath so strictly speaking we would have to write a
specification for our Xpath sub-set and return this as a supported
dialect rather than falsely claiming Xpath support.

> In the GRUS, we defined three header elements, the schema of which
> are as follows:

> a) wlcgrus:GroupBy
>
> With this header, the user can interrogate a RUS service endpoint without using XPath, but explictly identifying desired usage metrics to be returned.
>
> The groupBy element can be used for both job and aggregate/summary usage query by specifying the //urf:GroupBy/@aggregate value.
>

I like this. I'd have no trouble implementing this with my code base
nor would it be difficult to use it as a target for my report
generator code.

If these elements were included in the specification I see no reason
to include any SHOULD recommendation for a minimum supported filter
dialect.  Without them I think we would be better off upgrading the
recommendation to Xpath-2.0 as it is at least fit for purpose. 
Obviously my preference would be to include the additional header
elements and remove the recommendation.


 	     		Stephen


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