> - page 6: what's the difference between a null and an unknown vale?

By null I mean something like a 0-length string, i.e. there is a value but it's empty - whether that makes sense will depend on the context. I'll add a brief explanation.

> - page 7: the difference between WARNING and INFO is rather fuzzy: the
> former applies to values "likely wrong", the latter to values that "seem
> unlikely". I would advise a better choice of words to mark the difference in
> meaning;

There's intended to be quite a big difference. INFOs are lint-type checks that would normally be disabled because there will probably be a lot of false-positives, whereas WARNINGs will usually be real problems with a small number of false positives. I'll try to clarify that. 

> - page 7: why a difference in character case is a WARNING and not an INFO?

In general I think it would be a bad idea to have more than one valid value differing only in case. I'll add a comment that it could be an INFO for something like a free-text string.

> - page 10: is it possible to specify compliance with more than one type of
> profile (there may be other beside EGI) and more than one version per
> profile?

In theory it could be possible to publish non-EGI profiles, but since this document defines only the EGI profile it can't really be specified there! This method doesn't allow a single object to publish compliance with more than one profile or version, but I think that's OK. Either profile updates are backward-compatible in which case higher versions imply lower ones, or they aren't in which case it only makes sense to publish the exact version. I'll add some text for clarification.

> - page 17: to what extent is it assumed that all published services appear in
> the GOCDB and viceversa?

This is still under discussion, but the intention is for the BDII and GOC DB to converge. However there are services in the GOC DB (e.g. the GOC DB itself!) which are unlikely to be published in the BDII, so I'll modify the text a bit.

> - page 17: probably it is out of ignorance, but the purpose of the Capability
> attribute is not clear to me: what could be a real-life example?

This is part of the main schema rather than the profile, and I think the real-world use is still unclear. An example is that the WMS publishes Capabilities of executionmanagement.candidatesetgenerator, executionmanagement.jobdescription and executionmanagement.jobmanager, which could also be published by other kinds of workload managers with different interfaces.

> - page 18: same question about Complexity: I really don't understand what it
> is for;

Again this is part of the main schema; it counts the number of endpoint types and the number of Share and Resource objects. I'm not sure that it's all that useful but it does provide some checks in case expected objects are missing.

> - page 18: the StatusInfo attribute is not described in the text.
> Actually this happens for dozens of attributes in the following tables.
> Is that because the document is a draft, or simply the reader should refer to
> the schema document?

The latter - in section 1.4 it says

"The rest of this document consists of detailed specifications for each schema class and each attribute within the class, in the same order as the schema specification. Information in that document is not repeated here except as needed for clarification." 

> - are the possible values of HealthState listed somewhere? Here only "ok"
> and "warning" are mentioned;

All the enumerated types are either defined in the schema document or in a repository maintained by the GLUE WG. I'll add a comment in the introduction.

> - page 26: what is "post-execution" for staging jobs?

It means the user job has finished but the output files are still being copied out. I added a bit more text.

> - page 29: how many nines constitute the placeholder value?

As many as will fit - see http://glue20.web.cern.ch/glue20/#a8

> - page 30: what's the point in a MinCPUTime attribute?

I'm not sure if any of our sites do it, but it's an allowed configuration - a site may want to stop short jobs going to a long queue (which happens quite a lot in our standard configuration).

> - page 32: the "standard algorithm" for the EstimatedAverageWaitingTime
> should be documented somewhere, otherwise it's pointless to tell the
> developers that they SHOULD use it. They cannot be forced to take some
> obscure code and use it as a black box;

I think the code is now maintained by the CREAM developers so I'll see if I can get a reference for it.

> - page 32: attributes like MaxWallTime, MaxCPUTime etc. are not (or surely
> not only) for SD, but for SS, while the table does not put a checkmark in SS;

In general SS is for dynamic attributes like the number of free slots, and the MaxXxx limits are static, i.e. you use SD to find all queues with an acceptable time limit and then use SS to decide which one to use. I suppose it is technically possible that you might prefer queues with a larger time limit within that but I'm not sure if anyone does that, or how you would weight it against other ranking attributes. I'll think some more about it - I suppose I could mark them as potentially usable for SS.

> - page 36: what are the WorkingArea attributes for?

The WorkingArea is the disk space available to jobs on WNs, either local or NFS-mounted. We've never yet figured out how to publish or use the information, but the schema is ready! Comment added.

> - page 36: shhare -> share;

Fixed.

> - page 38: is it really sensible to publish things like TmpDir in the information
> system?

I don't know - the profile says Optional. I think it was originally suggested for a Grid with a different way of working to EGEE, but I don't know if it's ever been used in practice.

> - page 43: shouldn't the ToStorageService class have an attribute with the ID
> of the Storage Service? The local and the remote (?) path are surely not
> enough;

There are also relations to the relevant Computing and Storage Services. I haven't included relations in the tables because validation is complicated, but I should probably add some more general text (Maria also asked for it).

> - page 49: why TotalSize etc. should not be used for Service Selection?

That's the same kind of argument as for your comment about the MaxXxx computing attributes; my expectation is that you would select on the dynamic FreeSize rather than the static Total, but again I'll think some more as that may not be the whole story.

Stephen