[RUS-WG] RUS implementd on relational database

[Xiaoyu Chen]

  Stephen wrote:
 
>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.
 
I am not sure about how general the tool should be to support "full" xpath. But i do agree with a separate specification required for the tool usage. Em.., naming it as a different supported dialect rather than XPath support?  i am not sure, if you have additional syntax or gramma defined. But if XPath sub-set syntax, may be just claimed as partially xpath support? I do have a seperate document for XPath2Hql tool.
 
>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.

That's perfectly true! but as you can see from the syntax, the <wlcgrus:group> is semantically different from query, 'cos the definition of this element was originated from the idea to support service-side aggregation. (see RUS roadmap, the advanced spec.). Yes, i agree, if this element is used in RUS Core spec., then the miminum support to XPath can be removed. I think the new core RUS spec. does remove such recommendation. If you mean current RUS spec. (version 1.7), then i think there are more issues to be solved than this point. 
 
cheers!
 
 
X. Chen
 
BITLab
School of Engineering and Design
Brunel University, Uxbridge
Middlesex, UB8 3PH
London