> The National Grid Service (www.ngs.ac.uk) will use the UR schema instance to 
> define the accounting records it produces.  The comments are a result of the 
> experience gained in implementing a RUS service.
> 
> Comments regarding draft March 2005
> ============================
> 1)	Multiple levels of definition are confusing; sections 10 and 11, repeat and
>  sometimes alter the definitions in sections 1 through 9.

The structure of the document is designed to provide context and specificity for all elements of the recommendation. 
This structure will stand for V1, but need not be utilized for V2.

> 
> 2)	The appended schema mandates the inclusion of the "status" field.  This is 
> described as a must in section 3.9 but is not specifically included as a must 
> in section 10.6.  Further the allowed values in 10.6 are not enforced in the 
> Schema (this might be okay as other values are allowed).  Suggest that this is
>  removed as a mandatory record as it is not applicable in the general case (
> what about data records?)

By consensus, Status remains a required attribute, with data type "string" (which is a correction to the reviewed 
document). Required enumerated values have been added to the schema (Appendix D).

> 3)	Queue fields are provided for, but not the batch system on which the queue 
> resides.  Suggestion to add <Backend> tag or equivalent for systems that run multiple 
> batch systems. e.g., PBS, SunGrid Engine, Fork. Note: The "Resource" field 
> could be used to describe this but for consistency the queue should probably 
> be described here to and not as a separate entity.

Meta-property "description" can be used to include more detail.
 
> 4)	A Resource Broker is different from a meta-scheduler (provided for by 
> Global-job-id), suggest an additional field to capture jobs from a resource 
> broker (which may themselves use a meta-scheduler)

Out of scope for V1; please consider contributing this to the V2 discussions.

> 5)	How ambitious is the scope of a Usage Record? For job accounting it's 
> likely to be successful.  However the current extensibility mechanism and pre-
> defined fields, I suspect, will make life very difficult to try to capture a 
> Usage Record for a database resource or file store (whatever form they may 
> take�)

V1 is a job-level accounting record, based on common practices in the community. As accounting & consumption concepts evolve for non-compute/non-traditional resources, it is anticipated that the usage record recommendation will also mature. V2 is in the works; please consider 
contributing to that discussion.