[ur-wg] Meeting Notes

[Matthew Ford]

Quoting "Donal K. Fellows" <donal.k.fellows at manchester.ac.uk>:

> Future version to extend to more complex things than batch system job
> accounting.

But I think think we have this now!  Maybe I'm reading too much into the term
"extend".  It's much more a change of method and clarification that I would
like to see.  As you move through-out the document it becomes increasingly
generalised.  By section ten, I believe the current specs clear 
intention is to
be able to account much more than a batch job.  However it's not with out
problem.

Some thoughts and quotes:

- Job Level Accounting from the Original Spec is supposed to work at the batch
job level.  It is restricted form of the usage of the base properties of
section 3 or later the common properties of section 10.

 From Sec.4: "Job level accounting reports accounting data at the job 
level. PBS
and LoadLeveller.  This type of usage record MAY contain any of the base
properties. This type of usage record MUST contain at least one of the
following properties:o LocalJobId o GlobalJobId"

- Aggregate Accounting is specifically allowed, and integral to the 
current doc.

 From Sec.5: "Aggregate accounting reports the accounting data in aggregate
(summarized form). Aggregate accounting MAY contain any of base properties
listed in this document,"

 From Introduction: "Aggregation: Most sites have indicated that job-level
aggregation is sufficient for their current needs. Where sites aggregate or
decompose to other levels of usage tracking, provisions are
available within the schema to accommodate."

 From Sec.3: "Base Properties: The following is a list of base properties that
define common usage record requirements for both job level and aggregate
properties."

- The Global definitions in sections 7,8 and 9 clearly intend to setup 
a generic
framework in which most types of usage can can be accounted.
  + Sec.7 sets-up Global Elements to allow substitution for inclusion 
into other
schemas.
  + Sec.8. sets-up Global attributes sets up generic attributes which maintain
meaning independent of context. i.e, forcing common usage of units.
  + Sec.9. specifically sets-up a *generic* usage record

 From Sec.7 "The global definitions are those that may be used compliantly with
this specification as root elements for an XML document or which may be 
used as
extension points within or included within other XML Schema definitions."

 From Sec.8 "Global attributes, and attribute groups, are attributes that are
common to many of the element definitions contained in this specification. A
global definition of these maintains standard semantic meaning within each
context that they are used."

 From Sec.9 "UsageRecordType Complex Type: This complex type definition
establishes the structure of the *generic* usage record."

- Section 10, Usage Record Common Properties is an obivious attempt to
generalise the base proprieties of section 3.  The problem is that not all the
base properties of section three are appropriate as Common Properties for a
*generic* record.  Further as the bulk of section 3 is seemingly based 
on batch
level reporting, the scope of the section is serverely limited.

 From Sec.10 "10. Usage Record Common Properties: the complete 
specifications for
each element that MAY appear in the *generic* usage record are 
presented below."

>
> Stick with using email for resolving issues; not worth changing
> technologies half way through.
>
> Short-term Timeline:
>   Mailing list discussions to close: 30 June
>   Consensus: 15 July
>   Revised document: 15 August
>   Submit to editor: 1 September
>
> Three-way joint meeting: OGSA RUS UR
>
> Call for use cases and reference implementations
>
> Telecons
> ========
> Keep going. Biweekly. One hour. 1300 UTC. First on 25 May.
> ----------------------------------
>
> Donal Fellows.
>
>