LAST CALL - Usage Record Format Recommendation - Version 1
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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
Minor minor faults: * Extra comma in page 4, line 43 * Merge sentence fragment at start of page 6 line 10 with previous sentence. * Extra comma in page 6, line 11 * Extra space at page 7, line 6, col 45 * Should Unix be UNIX at page 8 line 9? * Section 4 descriptive text (page 11, lines 19-22) is in 12pt, which is inconsistent with 11pt used elsewhere for text of equivalent importance. * Bullet sizes are inconsistent at equivalent levels across many pages (note that this is often very hard to fix; Word is terrible at getting this sort of thing strongly consistent in my experience. Given that, not fixing this point is acceptable.) * Too many blank lines before section 5 heading (page 14, line 9-10) * Should specify (page 15, lines 7,16) that following an external specification for how to name an element or attribute trumps the rules for underscores, periods and dashes. * Should specify (page 15) that attributes should be qualified by the UR schema namespace. * Extra space in 7.2.5.2 heading (page 16, line 12) * Appendix D title is in wrong style; must have been marked as Courier, 9pt by accident. * Remove hyperlink style from the schema namespace names; namespaces aren't (necessarily) real URIs. (page 17 lines 15,22,28,34) * Extra blank line on page 17, line 14 * Section 9.1 header should begin with lower case letter * Please indent (or otherwise render visually distinct) the example on page 35, line 34 * The sample usage records (section 14, pages 39-40) would probably benefit from being in 9pt text so that strings (e.g. the record id) need not be broken at unfortunate locations * The cells of the survey results table (section A-2, pages 44-49) would be better off being marked as having North West cell alignment * Replace "I/ O" with "I/O" in A-2 table * Replace "X509" with "X.509" in A-4 table (page 50) * Appendix C should note that SI usage requires "kiB" for 1024 bytes, "MiB" for 1024 kiB, etc. It's stupid, but "standard". It's also a large part of the reason why JSDL dropped putting units in. :-\ * There is an extra "- " at the start of the second line of appendix D (page 53, top) * There are several extra "- " at the start of some lines on page 54, lines 48-51 [These last two are artefacts of the XML viewer in Internet Explorer] Of these, only the units matter is of any significance (i.e. might trigger a schema change or insertion of text) and we could just define that to be "wrong" in an SI sense. :-) Everything else is really just cosmetic. Donal.
-----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Tuesday, September 19, 2006 7:10 AM To: Mailing List for UR-WG Subject: Re: [UR-WG] LAST CALL - Usage Record Format Recommendation - Version 1
* Appendix D title is in wrong style; must have been marked as Courier, 9pt by accident.
By design, so that the lines don't split unnecessarily (see your comment about setting the Examples in setion 14 to Courier 9pt).
* The cells of the survey results table (section A-2, pages 44-49) would be better off being marked as having North West cell alignment
What does "North West cell alignment" mean?
* Appendix C should note that SI usage requires "kiB" for 1024 bytes, "MiB" for 1024 kiB, etc. It's stupid, but "standard". It's also a large part of the reason why JSDL dropped putting units in. :-\
What is "SI Usage"? How should this be noted in Appendix C? Everything else has been corrected or is OK ("extra commas" are a British versus American issue :)). 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Laura F McGinnis wrote:
* Appendix D title is in wrong style; must have been marked as Courier, 9pt by accident.
By design, so that the lines don't split unnecessarily (see your comment about setting the Examples in setion 14 to Courier 9pt).
Well, I'd put the appendix title at least in the usual font; the font size is less irksome there. Not that I mind if the title wraps; it's line wrapping in the middle of an XML attribute value that I don't care for.
* The cells of the survey results table (section A-2, pages 44-49) would be better off being marked as having North West cell alignment
What does "North West cell alignment" mean?
Umm, it means "top left". I tend to think of cell alignments in terms of compass directions. :-) In table cells you can control not only whether they are left or right aligned, but also whether they are top/bottom aligned (used when they don't fill all the space available due to other cells on the same line having more visual lines of content). When I set this in my documents, I select the cells I want to change, right-click to get the context menu and pick the likely looking thing off a submenu.
* Appendix C should note that SI usage requires "kiB" for 1024 bytes, "MiB" for 1024 kiB, etc. It's stupid, but "standard". It's also a large part of the reason why JSDL dropped putting units in. :-\
What is "SI Usage"? How should this be noted in Appendix C?
Apparently, we're supposed to use 1MB to refer to 1000000 bytes and 1MiB to refer to 1048576 bytes (== 1024kiB, 1kiB == 1024 bytes). I hate this usage, but it is standard. http://en.wikipedia.org/wiki/Binary_prefix has lots of gory details, including links to more discussion. I prefer to put everything in bytes or bits and use very big numbers. :-)
Everything else has been corrected or is OK ("extra commas" are a British versus American issue :)).
I just highlight them because Word's grammar checker doesn't like them (and yes, it was using the US grammar engine at that point). :-) Donal.
-----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Thursday, September 21, 2006 6:40 AM To: Mailing List for UR-WG Subject: Re: [UR-WG] LAST CALL - Usage Record Format Recommendation - Version 1
Laura F McGinnis wrote:
* Appendix D title is in wrong style; must have been marked as Courier, 9pt by accident.
By design, so that the lines don't split unnecessarily (see your comment about setting the Examples in setion 14 to Courier 9pt).
Well, I'd put the appendix title at least in the usual font; the font size is less irksome there. Not that I mind if the title wraps; it's line wrapping in the middle of an XML attribute value that I don't care for.
Will do.
* The cells of the survey results table (section A-2, pages 44-49) would be better off being marked as having North West cell alignment
What does "North West cell alignment" mean?
Umm, it means "top left". I tend to think of cell alignments in terms of compass directions. :-)
Ah, OK. Thx.
* Appendix C should note that SI usage requires "kiB" for 1024 bytes, "MiB" for 1024 kiB, etc. It's stupid, but "standard". It's also a large part of the reason why JSDL dropped putting units in. :-\
What is "SI Usage"? How should this be noted in Appendix C?
Apparently, we're supposed to use 1MB to refer to 1000000 bytes and 1MiB to refer to 1048576 bytes (== 1024kiB, 1kiB == 1024 bytes). I hate this usage, but it is standard. http://en.wikipedia.org/wiki/Binary_prefix has lots of gory details, including links to more discussion.
I prefer to put everything in bytes or bits and use very big numbers. :-)
Yeah, but I know there are sites that aren't as comfortable doing this. I'll look into this one some more.
Everything else has been corrected or is OK ("extra commas" are a British versus American issue :)).
I just highlight them because Word's grammar checker doesn't like them (and yes, it was using the US grammar engine at that point). :-)
Ah, yes. I'd forgotten about that hideous Microsoft dialect. I turned grammar check off years ago. :) Thanks for the comments. I'll work them in. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have updated Appendix C to note the differences between SI prefixes and binary prefixes. Rather than mandate one over the other, I have added the text: "Usage record measures of volume should use the appropriate terminology for referring to units. For measurements based on powers of 2 (2^10, 2^20, etc), the prefixes for binary multiples should be used. For measurements based on powers of 10 (10^3, 10^6, etc), the SI prefixes should be used." I have also included charts from NIST, which are based on the IEC standards. If this is not sufficient, please let me know. Thx LM
-----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Thursday, September 21, 2006 6:40 AM To: Mailing List for UR-WG Subject: Re: [UR-WG] LAST CALL - Usage Record Format Recommendation - Version 1
* Appendix C should note that SI usage requires "kiB" for 1024 bytes, "MiB" for 1024 kiB, etc. It's stupid, but "standard". It's also a large part of the reason why JSDL dropped putting units in. :-\
What is "SI Usage"? How should this be noted in Appendix C?
Apparently, we're supposed to use 1MB to refer to 1000000 bytes and 1MiB to refer to 1048576 bytes (== 1024kiB, 1kiB == 1024 bytes). I hate this usage, but it is standard. http://en.wikipedia.org/wiki/Binary_prefix has lots of gory details, including links to more discussion.
I prefer to put everything in bytes or bits and use very big numbers. :-)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
Hi everybody, since I am new to XML and this list, I probably am going to make a redundant or simply wrong point. I just have some thoughts about the A1 proposal of Rosario: First of all I think that version handling is very important, especially since I guess that the UR spec is going to change in the future. My question is, is not the XML namespace attribute (xmlns="...") telling the parser what exactly the XML document may look like. Since a new version will have some changes in what XML tags can and cannot be used, should it not have a new namespace. In this case, versioning could be done via well known namespaces that different tools can recognize (and know how to fetch the schema for and how to interpret the tags). In that case the version attribute seems to be redundant. If the XML namespace is not changed for a new version would it not make some of the old URs invalid if e.g. a tag was removed from the new version, plus make some invalid old URs valid if they conform to the new version? So to sum up I think that the XML namespace could be used to mark the version of a UR. Please correct me if I am wrong! Best Regards Gilbert Netzer Rosario Piro wrote:
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).
Gilbert Netzer wrote:
So to sum up I think that the XML namespace could be used to mark the version of a UR.
I agree. The point isn't that the namespace changes as such. Instead, the qualified name of the outermost element changes, and it is that which makes the records completely distinguishable. Version attributes are only useful in those cases where the content is changing in some way that isn't covered by existing extensibility, but the outer tag with the version number is *not* changing, and their usefulness is because they allow early rejection of the document (or backend parser adjustment so that the doc can be parsed smoothly). Donal.
Gilbert, Donal, and Rosario: I apologize for the somewhat dated reply. This particular issue was resolved last month when we modified the document to bring it into compliance with GFD.58 which deals specifically with creating a standardized xml namespace, and in particular with versioning based on the year and month of the publication for the specification. I hopes this helps. Cheers, Chris On Thu, Oct 05, 2006 at 09:54:24AM +0100, Donal K. Fellows wrote:
Gilbert Netzer wrote:
So to sum up I think that the XML namespace could be used to mark the version of a UR.
I agree. The point isn't that the namespace changes as such. Instead, the qualified name of the outermost element changes, and it is that which makes the records completely distinguishable. Version attributes are only useful in those cases where the content is changing in some way that isn't covered by existing extensibility, but the outer tag with the version number is *not* changing, and their usefulness is because they allow early rejection of the document (or backend parser adjustment so that the doc can be parsed smoothly).
Donal. -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
--
Christopher A. Baumbauer
Hi Laura and folks, It looks like taking too long to close the last call. What is your plan for the editor submission of your document? If there is anything Ellen or I can help, please let us know. Thanks, ---- Hiro Kishimoto and Ellen Stokes, Management Area Director 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
participants (6)
-
Christopher Baumbauer -
Donal K. Fellows -
Gilbert Netzer -
Hiro Kishimoto -
Laura F McGinnis -
Rosario Piro