Hi Donal, I have some comments/questions on your latest release of the proposed 2.0 spec. - It's much more legible now; your effort in this is much appreciated by me at least! :-) - I like the much cleaner type derivations. - With regard to the AtomicActivityUsageRecord type: * I don't like how we call it an AtomicActivity and then use "JobName" as an element name. The activity may have nothing to do with jobs; I still feel as though we have a mix of the specific and generic in this type. * In a similar line of thinking I wonder if elements such as "Status" should not be global and instead be local to a derived type such as "AtomicActivity" i.e., declared instead of referenced. Not all Usage records will necessarily have "Status" and it's meaning can in principle vary wildly. - With regard to the CompoundUsageRecord: * It's abstract as you note; so how's it made specific? (the following questions may be due to my ignorance of XSD's). I guess I could extend the schema but how then do we make it so that people don't go off and arbitrarily extend it? How do we capture this if they do? For example if I naively defined a "grid-job" - treat this name as arbitrary ;-) - as the collection of AtomicActivity UsageRecords spawned by my Resource Broker (never more than ten) what do I do? Should I even attempt this: my aim is to extend the schema to allow only compound records of 0 to 10 Atomic Activity records only? <xsd:complexType name="GridJob"> <xsd:complexContent> <xsd:restriction base="usage:CompoundUsageRecord"> <xsd:element ref="usage:AtomicActivity" minOccurs="0" maxOccurs="10" maxOccurs="unbounded" /> <xsd:any namespace="#other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:restriction> </xsd:complexContent> </xsd:complexType> <xsd:element name="GridJob" substitutionGroup="usage:UsageRecord" type="usage:GridJob"> </xsd:element> Or should I be thinking of CompoundUsageRecord as plumbing for as yet undefined parts of the UR-WG schema? Cheers, Matt.