If we can find a POSIX statement of allowed chars, to support automatic "type" detection by lexical analysis, I think we should do "User" (no "name" or "id") and the polymorphic semantics. However, "sudo" requires a prepended "#" character to indicate a numeric ID in the generic username field of its command-line option syntax, so I am guessing POSIX may not have this guarantee. Otherwise, I think we should use "UserName" and the name-only semantics. I guess numeric ID is esoteric enough to handle through extensions if some subculture actually needs it? Or, would it make sense to just treat the numeric IDs as optional attributes on the elements? I guess we really want a mutually-exclusive specification of name/ID or else we need some sort of statement about consistency of these values? karl On Apr 13, Donal K. Fellows loaded a tape reading:
The telecon has decided to move the UID/GID bits from User to the POSIX version of Application (whatever that's called; I'm behind tracking the exact name of things right now). But a question has come up about the meaning of the content of these elements.
It is obvious that they have to be able to accept usernames in their xsd:string content (and I'm aware of systems with spaces in usernames, even if this is not something I'd ever do myself) since they're how POSIX user identities are exposed to users normal. However, with names like they have, should they also accept numeric UIDs? I don't have a use case for this (it's a detail I'd want to always hide) and I'm not aware of anyone ever having a wholly numeric username.
As I see it, we have three options: * Current name, user-name semantics * Current name, user-name-and-uid semantics * Change name (to UserName?), user-name semantics
Which do people prefer? (GID handling should mirror UID handling)
Donal.
-- Karl Czajkowski karlcz@univa.com