|
|
|
Morris Riedel: 10/16/2007 10:59 AM EDT
|
| |
Comment: |
Hi,
interesting document. However we should bring it somehow in a word document that people are able to use the "track changes" function and can comment
directly on the document. Usual procedure in other groups.
Regards,
Morris
|
| |
Action: |
Update
Assigned To changed from Gilbert Netzer to none (no value)
|
|
|
Gilbert Netzer: 09/21/2007 7:57 AM EDT
|
| |
Comment: |
After a little experimentation I have been able to use a single XQuery update statement (in this case with the eXist XMLDB in version 1.1.1) to
replace the contents of several usage records, thus emulating the behaviour of the old replaceUsageRecords operation:
for $new_ur in (<ur><id recId="1"/><val>New Value1</val></ur>, <ur><id recId="2"/><val>New Value2</val></ur> ), $old_ur in /urs/ur
where $old_ur/id[@recId=$new_ur/id/@recId]
return (update replace $old_ur with $new_ur)
The previous statement replaces two usage records in the collection with new contents supplied via the query. It is written in the eXist variant of
XQuery update, the current W3C draft variant would look the same but the word "update" replaced with "do".
While this demonstrates that the replaceUsageRecords operation can be moddeled using the modifyUsageRecords operation, the issue of including a
replaceUsageRecords operation into the specification is still open.
To further elaborate on the discussion, I want to post the following questions:
- Does your application use (or would use) the replaceUsageRecords operation and how frequent do you thing will this operation be?
- If yes is should this go into the RUS Core or RUS Advanced specification?
- Should this be a separate operation or should the modifyUsageRecords operation be extended with a query dialect that allows presenting a list of
usage records with replacements for existing records (the match would be done via the unique record identity attribute that may not be changed)?
|
| |
Action: |
Update
|
|
|
Gilbert Netzer: 09/21/2007 4:24 AM EDT
|
| |
Comment: |
I am a little bit confused about the presented use-case. If a client does not know what query, how should it be able to query the recordIds, both need
the same query?
The user needs in no case to be exposed to any XPath, the client which is software can have any interface towards the user and is the only part that
actually has to handle the XPath language (or any other query dialect for that matter).
So we should instead consider if XPath is good as the only option for use by the client, though I would advocate for keeping the number of mandatory
query dialects very small, preferably 1.
The extractSpecificUsageRecords could in the new specification be best modelled using a query dialect for the extractUsageRecords operation since this
was exactly the use case I had in mind for having query dialects. However if this is only to shield the user from XPath I would strongly suggest that
it is the clients job to wrap the user query into a suitable XPath statement which can be easily constructed by the client.
However I can see the following use-case for a more limited query operation:
First a client wants to get a limited amount of information for a large number of usage records to present a overview list to the user. Later on it
can request detailed information on specific records selected by the user.
In this case it could be interesting to not transfer all information up-front but only return the parts that the client is interested in.
For continuing the discussion on this thread, I want to suggest comments on the following questions:
- Do you think the use-cases presented for the more limited extractUsageRecordIds (or similar generalized operation) are relevant, e.g. is this
something your actually use in an application or plan to use?
- If yes, should this be part of the RUS Core specification or should this be offered in the RUS Advanced specification, e.g. is this a "showstopper"
for using the RUS interface or is it merely a nice to have feature that you can live without (that does not mean that it is not valuable and should be
considered)?
- Do you only need a very limited set of results from this operation (e.g. only the record ID value) or do you need a more general operation that can
return arbitrary parts of usage records selectable by the client (e.g. give me the recordId, the JobId and the startTime)?
- Should this be implemented as a separate opertion or is it better to generalize the extractUsageRecords operation to be able to return partial usage
records?
Thanks in advance for you comments!
|
| |
Action: |
Update
|
|
|
Xiaoyu Chen: 09/20/2007 7:02 PM EDT
|
| |
Comment: |
Here are my comments on RUS IDL spec
1). The service interface description should be clarified in a consistent way as defined in IDL spec especially in following particular points
:
RUS:extractUsageRecords need to re-defined as IDL spec. How about RUS:extractUsageRecordIds? This is an important operation as I can see. An
example usage scenario would be query specific usage record using urf:UsageRecord/urf:RecordIdentity/@recordId as a context node within xpath
statement. The client won't know the recordId value before querying. An auxiliary operation, RUS:extractUsageRecordIds would be helpful. For users
unfamilar with xpath statement, would it be better to have RUS:extractSpecificUsageRecords with a set of recordId values as parameters?
2). Most of modification operations (updates and deletions) defined within RUS v1.7 specs are reduntant. I totally agree to remove most of
them, except RUS:replaceUsageRecords. It is difficult to replace existing usage records using a single RUS:modifyUsageRecords operation.
|
| |
Action: |
Update
|
|
|
Xiaoyu Chen: 09/18/2007 7:53 AM EDT
|
| |
Comment: |
I like the idea that allows other query and update dialect extensions, which can be used align with WS-Enumeration spec.
|
| |
Action: |
Update
|
|
|
|
