Hi everyone! What with the cancellation of today's meeting, Matt Ford and I had a little ad hoc meeting discussing the things that bothered us about the specifcation as it currently stands. Now, we're coming from quite different perspectives (despite working at the same site) so it was interesting that there was quite a lot of agreement between us on ways in which it would be nice if the UR spec&schema evolved. So here are some notes based on my recollections of what we talked about: There seems to be confusion about what is going on with the difference between the UsageRecord element and the JobUsageRecord element. That needs to be clarified/cleaned up. Matt wants to be able to describe usage records for things other than atomic computational jobs (especially storage). The composition rules in the schema are waaaay complex! Probably too complex. Many UR parts are only meaningful to computational jobs, most of the rest are generic. Network bandwidth confuses both of us! A bad sign! It would be nice to have composite usage records, but we don't need aggregate URs. A composite should be a UR that has URs inside it, but does not present any aggregate info other than in the most general sense (e.g. "this is the global user identity associated with all this"). Anyone defining an aggregate might derive from this though. We should decide whether we're going to go down the road of having a type system or having highly specified elements. The first approach is the one that seems to be favoured by the OGSA information modelling crowd, and the second is what was eventually adopted by JSDL; I favour the second I must admit, in part because it is easier to build a good ontological model of everything then. Otherwise, you have to figure out how to understand all the ways you can put all the pieces together, when in fact some ways of doing stuff are meaningless. The second approach is also a bit easier to validate in XML Schema (though perhaps a bit more verbose). So, proposal is to divide terms into generic and computational job groups. Then define a parent UR type that just has the generic terms in it, an extension of that which adds the computational job terms, and a separate extension which does the composite/compound record (which might be useful for talking about MPI jobs). Other extensions could be defined in the future (and we'd set the WG up as the nexus for talking about such extensions, in a manner similar to the JSDL-WG is going) but we probably ought to limit ourselves for now. :-) The computational job UR should probably be called POSIXActivtyUR to link in with the vibe around JSDL and BES. That strikes me as being good GGF politics. :-) I've got some notes somewhere on how to make the schema obey all this while tooling up sensibly. Donal (I hope I remembered everything right...)