[RUS-WG] doc change request

[Xiaoyu Chen]

Rosario wrote:

>But first let me say: I think we shouldn't work contemporarily on two versions of the draft (17 that went through >public comment and 19 that is a proposal of which some things have already been discussed and agreed, but >many changes are not "approved"). I would suggest to port the proposed changes that have been accepted to >version 17 and let that evolve step by step. For example: the removal of the wrapping RUS-UR and an additional >extractRecordHistory. 

I total agree one step evolvement at one time based on current version 1.7. However, if looking into the details of version 1.9, the main changes are mainly based on version 1.7 as what proposed on removing RUS-UR as first step. Since RUS-UR being removed, then a lots of context notes should be modified accordingly as well as service interface definitions. 

First of all, the chapter 5 (version 1.7) should be removed or modified to a few words saying the specification is based on OGF-UR format instead of RUS-UR. Then section 6.1.2 (version 1.7) should be changed as well. The RUSRecordId element of RUSRecordIdList should be "urf:recordId" as xsd:string type.

Then coming into the details of Service Interface Definitions: Extraction SIDs:

1). RUS::extractRUSUsageRecords is intended to be redefined as "RUS::extractUsageRecords" with output as URF elements. 

2). RUS::extractRUSRecordIds should be changed into "RUS::extractRecordIds" as well. Besides, i cannot see any reason for defining this operation in version 1.7, except being used as an auxiliary operation for client-side to obtain relevant usage record identities. But how these usage record identities can be used (Just because it is mandatory element defined in RUS-UR or OGF-UR?)

3). based on above context, the version 1.9 proposed RUS::extractSpecificUsageRecords allowing the client side to query usage records with a set of record identities. So as you can see, the version 1.9 is total evolved from version 1.7 with agreed changes except for additional faults with well-defined fault framework. Maybe version 1.9 should not be named as version 1.9, 'cos it is actually a mantenance of version 1.7 and should be version 1.7 as well. 

If you all agree on this, then i will modified version 1.7 accordingly without changes on faults framework. But additional RUS::TooComplexFault should be added which has no effects on operationResult element. That is because the operational result aims at giving fine-granularity operational result for batch processing, which is out of the scope of "TooComplexFault" definition.

(tracker: http://forge.ogf.org/sf/go/artf5934?nav=1)

cheers!