[UR-WG] [RUS-WG] Minutes from the OGF20 sessions

[Donal K. Fellows]

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.