Sure, I can give a summary to get started with. Essentially, these features bring to the web services the features that you normally have in the UI of a portlet. These have been present in Clarity since 12.1.2 and v13 and up, and have an enhancement request identifier of CLRT-61705 "Support sorting and pagination from XOG Query API".
Slice: Rather than a monolithic dump of data (even if filtered) in one go, you now are able to fetch chunks of that data. You specify the number of records per 'slice' of data and also the the numbered slice you are interested in. Exactly like grid portlet pages; you can choose there for example to have 20, 40, or 50 records per page, and you can jump to or view any one of those pages. The 'total' attribute you are given in the output is to help guide you, so that even from the first page of results you should (through a simple division) be able to determine the maximum page possible to display too.
Sort: Without an explicit sorting capability, the above feature on slicing/paginating would be diminished. If the records all came out in a pseudo-random order for a given column, how do you know if you want to go a page forward or back to get to the results you want? So this is just a natural extension of not receiving all records at once. If you're not doing a slice/page but fetching all results, I would probably say skip this since XML and XSLT is quite capable of sorting data itself otherwise.
FilterExpression: To go beyond the automatic filter options given to you, whether that normally comes from having a column in your SELECT list, or through @WHERE:PARAM:USER_DEF:...@ entries for both single and multiple values, this new section will help cover other more complex variations and cases (such as over whether to use AND's or OR's dynamically through a more powerful query building UI tool - something you couldn't otherwise control without a lot of convoluted query logic) by letting you put in a specific filter WHERE clause section of your own at the time you call the query rather than just in its upfront design. This is a literal replacement for one of the "... AND 1=1" placeholders that would otherwise appear in the WHERE @FILTER@ section, you would provide it as you would write any SQL that you'd append to a WHERE clause.
As a basic example. The request format should be in the form of:
<Sort>
<Column>
<Name>nameofcolumn</Name>
<Direction>desc</Direction>
</Column>
[<Column>...</Column>]
</Sort>
<Slice>
<Number>pagenumber</Number>
<Size>pagesize</Size>
</Slice>
<FilterExpression>('something' = 'something')</FilterExpression>
Noting that each category (sort, slice, and filterexpression) are all optional. Just because you want to use one does not mandate the use of the others too. I've also omitted the namespace alias that might need to be prefixed, e.g. if using SoapUI to generate the requests, it would typically be like this instead: <quer:FilterExpression>(user_name = 'admin')</quer:FilterExpression>
The response should also contain the Slice information used in the request, including the total number of records:
<Slice>
<Number>x</Number>
<Size>y</Size>
<Total>z</Total>
</Slice>
If no slice information is given in the request, then you'll get 0 for the (page) number and the y and z values for size and total will be the same (the total number of the records returned).
I hope that helps - give it a try and the pieces should all fall into place in a way that makes sense.