Karl Czajkowski wrote:
I had a thought on the flight home... isn't the user and group naming really part of the POSIX executable-application type, just like the limits turned out to be? [A side comment is that they are mislabled for POSIX: userName should be a string, and UserID if it exists should be a number, etc.]
I'd be very tempted to say that actual uids should not be exposed, as they are very much a concrete concept (i.e. unportable). I could also envisage a system that says that if the element contains a number, it interprets it as a uid and otherwise it looks it up as a user name. But I wouldn't mandate such behaviour.
If we move them to the type-specific App syntax, the User section would become empty (since we already scoped away the userCredential element). I would advocate doing this and "garbage collecting" the User element from the spec 1.0, but I am certain I do not understand others' use cases surrounding this element.
We got rid of the credential? Must have been at one of the points when I was feeling too tired to pay attention. :^) If so, there's no reason (at the moment) to have User separate. (OK, an SQL query might well also want a username, but it could either borrow the execution element or invent its own). I'm not sure if that will continue to be the case though when JSDL is embedded within the wider context of a workflow language of some form. But then it could of course take the user information from some kind of parent declaration outside our scope. Donal.