[UR-WG] LAST CALL - Usage Record Format Recommendation - Version 1 (fwd)
Rosario Piro
piro at to.infn.it
Fri Sep 29 05:43:26 CDT 2006
(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 at psc.edu
> 300 South Craig St, #313 phone: 412-268-5642
> Pittsburgh, PA 15213 fax: 412-268-5832
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> --
> ur-wg mailing list
> ur-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/ur-wg
>
More information about the ur-wg
mailing list