Rosario Michael Piro wrote:
I've already a few considerations to some of the things we said at the sessions, maybe they can serve as a starting point for a discussion.
I put my comments inline where I have them. In other cases I either just agree or otherwise have nothing to say. :-)
- About the name: currently Aggregate Usage Record (AUR), or would the name Summary Usage Record/SUR be more appropriate, since aggregation can also mean just a set of single URs without summing the usage values up?
I think I'd prefer Summary UR. It's much clearer about it's purpose.
Proposed new properites of UR: - UserFQAN: The FQAN is indeed very well structured (as is the User DN), it is basically a string that indicates the VO and particular VO group a [...] Since VOMS is widely used (and for example charging might depend on a user's role in a VO) the notion of a user's role should be supported [...] exact form of it should then depend on the environment/use case. But that's just an idea.
I don't think that it should be an update to the UR itself, since it isn't going to be at all meaningful outside systems that use VOMS (and not all grids do; there are other ways to manage the same general effect). I therefore think it should be an element in its own namespace that VOMS-using grids can use without raising hackles from everyone else.
2) Comments to the minutes of the joint UR/RUS session: [I keep the UR-WG in CC for this, some of you might be interested in what is going on eith RUS; if not, just ignore what is following ;o) ]
Full XPath support vs. XPath limitations: - I wouldn't say that XPath queries destroy the performance, although [...] focus too much on that. The question is more whether we want the RUS interface to be completely XPath-compliant or leave the restrictions that are currently in place. I think full compliance is the better choice, above all since we're talking about standards :o)
Not just that, there are things you can do in particular implementations to improve performance (e.g. managed caches of prepared statements) that mean that there would need to be experimental evidence that *common* queries are slow (even after applying such tricks) for it to be worth chucking out XPath. I think this is something where implementation experience will be needed to determine the best way forward.
- If XPath will allow to retrieve only pieces/parts of URs: Why should a [...] against the spec. It is up to the client to check what it gets back (knowing exactly what it wanted back; entire URs for validation, just a list of job IDs, or whatever ...)
It depends on exactly what you want to support. If you're supporting general XPath (or XQuery) queries, you need a resulting content model that permits mixed unvalidated nodes. If you're only ever using it for determining what (full) records to return (i.e. by only returning those records for which the XPath query matches something) you can apply the type constraint safely.
- Also I think letting the RUS server inform the client about what queries it is willing to execute would be unfeasible since XPath is extremely flexible and listing all possible queries should be quite impossible (immagine all the possible combinations ...).
XPath is a recursive language; it has no theoretic bounds on query size. I'm pretty sure that there's not even a *countably* infinite number of queries. Moreover, this is a standard you're writing; implementations can impose and document such extra restrictions if they choose, but we have no inherent reason to do so ourselves.
- The idea of using XPath expressions for defining the mandatroy elements that have to be present for a UR to be accepted upon insertion is good since it is the most flexible one, also: if the client queries the RUS server for the mandatory elements it should be straightfoward for the client to test its UR documents against the servers requirements before trying to insert them into the RUS.
One method that is used elsewhere in OGF specifications is to declare a (read-only) property of the server that describes the profiles on the records that it supports. Each profile would be described by a unique URI, and would document how the UR is restricted (e.g. "must have this element, must not have that element, and the other element over there must mean something special"). The advantages of this are that it allows more complex assertions of what is acceptable and yet it is easier for clients to understand it (no need to parse complex XPath expressions!) That's all for now. ;-) Donal.