[Standards] XEP-0154: User Profile - comments
pavlix at pavlix.net
Mon Jul 28 21:48:36 UTC 2008
On Mon, 28 Jul 2008 16:07:24 +0100
Dave Cridland <dave at cridland.net> wrote:
(citations shortened, for the sake of readability)
> Right, I thought so too, initially. But data forms are well
> understood, and prevent people from going too crazy about these
> things. Ideally, I just want key=>value mapping, and I can just
> about deal with multivalued keys.
There is other craziness invited by data forms. First it's hard to
extend cleanly as there is no possibility to add a group with a custom
namespace. Second, client writers may tend to define their own
"global scope" fields. So the future extension would be near impossible.
Second, correct me, if I'm wrong... PEP with data forms will have to be
implemented entirely differently from PEP without them (at least this
is the point of specifying only some fields). And what more, it needs
different implementation on the server side.
On the other hand, a single item (a section with xml data elements)
needs just PEP on the server side... and the profile-specific stuff on
the client. Only advanced or temporary techniques like vcard mapping
or searching would need changes to the PEP-enabled server.
> Well, in principle, user images should be XEP-0084 avatars, so we
> lose this problem mostly.
I'm not sure about it. It depends if you keep separate avatar (changing
often) and user picture (e.g. for web search, changing rarely) or not.
> Yes, users could go overboard in how much information about
> themselves they define, but I've not seen this as a problem in
> practical terms with vCards except for the avatars.
Yes, except for the avatars, but there may be other stuff, e.g. an
"about text" or html-based about text (virtually a web page) if later
added. There may be other future usecases.
Anyway it seems useless to me to specify individual pieces of data in
any requests for data. Whole sections seem more reasonable to me (the
data should be logically connected, of course).
> > Home and work addresses are usually presented in separate tabs.
> > There
> > could be also usecases where home information is irrelevant or has a
> > different publishing policy than work information. What I'm not sure
> > about is the generic info, any suggestions?
> Yes, this is a problem for me, too. If you're pulling this stuff out
> of a directory, for instance, then LDAP defines work and home
> contact data, but not generic contact data - I can't really see that
> generic contact data would be anything except either home or work.
I think generic contact data should be generally avoided.
> > * In low-speed/expensive network environments we also benefit
> > from the
> > separation. The client program may download only the section the
> > user actually wants to see.
> Oh, be careful with this. The moment a user wants to see two items
> of data, they have to ask twice, which is more transmission, and
> therefore more cost.
I was careful. It's not two items but two sections, so...
1) it's not such a big data overhead if implemented
2) I just wanted to allow the client devs optimize this way if
appropriate and ignore the possibility if not.
> > what I suggest is to unify all contact addresses with the same type
> > (purpose). An example would be:
> > <im network="xmpp">stpeter at jabber.org</im>
> > <im network="xmpp">peter at saint-andre.com</im>
> > <im network="msn">petersaintandre at hotmail.com</network>
> > <im network="yahoo">psaintandre</im>
> > One might also consider other possible syntaxes.
> > This applies to:
> > * 6.4. Telephony Address Data Aspects
> > * 6.5. Electronic Address Data Aspects
> > * 6.6. World Wide Web Resource Aspects
> > Alternatively, we might call it always 'type' to make easier
> > mapping to
> > a relational database (but it doesn't help a generic PEP/pubsub xml
> > storage!).
> Even if you stick with forms, there's still a lot of truth here.
I would like to have this one solved
> > 5) Birthday / nameday
> > I very appreciate you can set individual parts of birthday.
> Of course, the whole thing gets hideous when using a back-end store
> which can only store a date.
What about a string? For the sake of usability in the public context,
where people choose only to provide partial info.
Still, how do you store other generic PEP data?
> > 6) Non-profile
> > There are some data included that don't seem to fit in the "static"
> > profile like geolocation. But maybe I just misunderstood their
> > purpose.
> My impression is that these are left-overs.
Then it's easy to get rid of them.
Jabber & Mail: pavlix(at)pavlix.net
More information about the Standards