(Since I'm having problems with our mail server I send a second copy of my mail hoping that at least one will make it :o) Sorry for an eventual suplication, Rosario) ---------- Hi all! I'm sorry for sending my comments on the UR spec for version 1 this late (but then, I still respect the deadline :o), but I was quite busy lately (as always) ... The list is quite long. Most points are just minor corrections, such as wrong references between Sections of the document, but there are some very important observations as well, so please read carefully through them! I'd appreciate some comments above all to A1 (proposal to have a version attribute for UR instances, and to also specify the version in the schema) since I think it is important. Cheers, Rosario. Here are my comments: ------------------------------------------------------- Comments on version 1 of the UR spec: IMPORTANT PROPOSAL: A1) Since we are currently finishing version 1, but are also thinking about version 2 we should make sure that different UR versions can be easily distinguished by processing software (e.g. accounting systems), this means the version should be specified in both, the schema itself (as part of the annotation) and each instance of a UR document. For example: <JobUsageRecord version="1.0"> (or <UsageRecord version="1.0">) ... </JobUsageRecord> Otherwise announting tools will have a hard time figuering out against what version of the UR spec they should validate a specific instance. The specification of a version should me _required_ for each instance. I am aware that this might imply problems for already existing implementations based on earlier drafts, but it will avoid a lot of trouble in the future (think about major changes in version 2, 3, 4, wheverever we will end up). INCONSISTENCIES IN THE DOCUMENT: B1) While the abstract talks says that "This format must encompass both job level accounting and aggregate accounting" and §6 briefly explains how to do aggregation, §1.1.2 explicitly states that the "document does not adress aggregation, summary records ... or anything other than an atomic resource.". Actually, the "aggregate" property mentioned in §6 is not part of the UR schema. This is more than confusing and will lead to problems. I suggest to remove all references on aggregation from the document (abstract, §1.2.4, §6, ...) and just leave the note in $1.1.2 to make clear that the current spec is not supposed to be used for aggregated accounting data. B2) §2.3.6: "Timestamp" should actually be called "dateTime". B3) §3: What is called "Basic" Properties here is called "Common" properties in §11. B4) Are §3 and §4 necessary since they correspond to §11 and §12, respectively? It would be more appropriate to unite Sections §3 and §11, and §4 and §12, since it is confusing if information on the same property has to be looked up in different parts of the document. B5) §3.1 says the RecordIdentity property MUST have data of type string, while this element actually contains no data. The identity of the record is instead specified in its "recordId" attribute. B6) §3.1 says that the create time of the record is required, while it actually is optional according to the schema B7) §3.2, §3.3 and §3.4: The "description" attributes mentioned here are not in the schema. This seems to be an artifact from previous UR versions where GlobalJobId, LocalJobId and ProcessId where distinct resource properties and not part of the JobIdentity property. B8) §3.4 says ProcessId is of type integer, while the schema says it's a string B9) §3.12 and §3.13 mention data type "timestamp", it is preferable to use "dateTime". B10) §4.1, §4.2, and §4.3 say that "Units MAY be specified", it might be better to directly refer to intervallicVolume B11) §4.4: "metric", "type" and "intervallicVolume" (or units) are not listed. B12) §4.7 and §4.8: "description" and "type" are not listed. B13) §4.9: "type" is not listed. B14) §4.10 seems to be obsolete be cause it talks about an "Extension" property while now we have "Resource", "ConsumableResource", ... B15) §5 says that each record must contain at least one of LocalJobId or GlobalJobId while their parent property (JobIdentity) is optional according to the schema. B16) The schema does contain the old enumeration for storageUnit and not the new one described in Appendix C (prefixes for binary multiples and SI prefixes for negative exponents are missing int the schema) B17) not all schema excertps in §11 and §12 correspond to the complete schema in Appendix D. Please update the exceprts to the final schema version. (e.g. excerpt in §11.1 contains "createDate" while schema and description contain "createTime") B18) §11.3.2: should be "GlobalUserName" instead of "GlobalUsername" B19) §11.6: The values that have to be supported are listed with all letters being lowercase, while the annotation in the schema in Appendix D describes them with the first letter being uppercase. This is only a slight error, but may cause problems for implementations that are case-sensitive. B20) §12.1, §12.2, §12.3 and §12.4: "intervallicVolume" is missing in the list of attributes B21) §12.7.1 and §12.8.1: the schema in App. D does not contain a "description" attribute for TimeDuration and TimeInstant! Either add it to the schema or remove it from the description. B22) §13.1.2.2: "unit" should be "units" according to the schema B23) The last note in App. B (that the Appendices are included for historical reference) should better be on top of the Appendix instead of being at the end (where it can easily be overlooked) WRONG REFERENCES: The follwing observations refer to the current numbering of the Sections. If §3 and §4 should be removed (see comment no. B4) the references change accordingly: C1) in §3, 1st paragraph: the reference to §8 since that Sections doesn't contain basic data tye definition. C2) in §2, 2nd paragraph: reference to §8, should be: §9 C3) in §7.2.6: reference to §10.1, should be: §11.1 C4) in §7.2.8: reference to §12, should be: §13 C5) in §9.5, on page 20: reference to §11.2.2, should be: §12.2.2 C6) in §9.5, on page 21: references to §10 and §11, should be: §11 and §12, respectively C7) in §9.6: references to §11.2.3, §10 and §11, should be: §12.2.3, §11 and §12, respectively C8) in §10.1: references to §10.1 and §10.6, should be: §11.1 and §11.6, respectively C6) in §11.1.2: reference to §6.2.5, should be: §7.2.5 C7) in §11.1.3 on page 25: reference to §6.2.7, should be: §7.2.7 C8) in §11.4: reference to §10.2, should be: §11.2 ------------------------------------------------------- On Sun, 17 Sep 2006, Laura F McGinnis wrote:

Please review Version 1 of the Usage Record Format Recommendation. It is on our gridforge repository at https://forge.gridforum.org/sf/go/doc13864?nav=1, and also on the usage record website maintained at http://www.psc.edu/~lfm/PSC/Grid/UR-WG/.

Please send all comments to the mailing list by 1 October 2006. After that, the document will be submitted to the OGF Editor.

Thx LM

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Laura F. McGinnis, Project Coordinator Data & Information Resource Services Pittsburgh Supercomputing Center email: lfm@psc.edu 300 South Craig St, #313 phone: 412-268-5642 Pittsburgh, PA 15213 fax: 412-268-5832 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg