Re: [Standards] XEP-107 and XEP-108: Empty Value?

[Peter Saint-Andre]

On 05/05/2008 3:59 AM, Florian Zeitz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Saint-Andre wrote:
>> Hmm. We didn't think about this case enough when we defined all these
>> personal eventing payloads.
>>
>> IMHO, for personal eventing there is a difference between (1) deleting
>> an event and (2) setting your state back to neutral. #1 rewrites history
>> by effectively saying "well no I didn't have that last mood, please
>> ignore it" whereas #2 says "yeah I was angry before but now I'm not". If
>> we use personal eventing payloads as input to lifestreaming systems then
>> I think we want to preserve the history but define neutral states for
>> all of these.
>>
> I'd personally interpret it a bit different (but that's just personal
> opinion).
> If you delete a node you're not really rewriting history, because when
> there was a node back then one would assume that it was valid at that
> time but isn't after it has been deleted.
> Setting your state back to neutral has a different problem and that is
> "What does that mean?"
> Mood for example actually defines "neutral" as a mood, and that is
> fundamentally different from "I'm not telling you how I feel" IMHO.
>
> To take up your example of a lifestreaming system:
> Let's say I'm listening to some Fiddler's Green Song. The lifestreaming
> system might show:
> "Florob is listening to Fiddler's Green - Drive Me Mad - Irish Air"
> Now I stop my music. The system says
> "Florob has stopped listening to music."
> Now let's say I decide to not tell anybody that I enjoy listening to Die
> Ärzte too. I'll turn off User Tune.
> Now what should I do?
> I can either set a neutral state, which will probably show
> "Florob has stopped listening to music."
> which is a lie.

That seems a bit strong. :)

> Or I can delete the node, which according to your definition would
> change history. I personally think it should mean:
> "Florob has stopped telling us his taste, that evildoer"

It seems rather messy to delete the node and then re-create it all the
time. For example, lots of geolocation services enable you to specify
certain locations that are private. So when you move to a private
location, you want to stop publishing temporarily. But you might start
publishing again 20 minutes later or whatever. So why delete the node
(along with all its subscriptions) only to re-create it so soon?

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Dave Cridland]

On Fri May 23 05:11:14 2008, Peter Saint-Andre wrote:
> It seems rather messy to delete the node and then re-create it all
> the
> time. For example, lots of geolocation services enable you to
> specify
> certain locations that are private. So when you move to a private
> location, you want to stop publishing temporarily. But you might
> start
> publishing again 20 minutes later or whatever. So why delete the
> node
> (along with all its subscriptions) only to re-create it so soon?

Could we not define some way of positively indicating a lack of
information?

Say, a <mu/> element, which could either go inside a <tune/>, or
replace it entirely within the node. (I'm here using "mu" as an
acknowledgement of the question but a refusal to answer it, serious
Japanese/Zen people can laugh at my ineptitude in using the word
"without").

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Florian Zeitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> It seems rather messy to delete the node and then re-create it all the
> time. For example, lots of geolocation services enable you to specify
> certain locations that are private. So when you move to a private
> location, you want to stop publishing temporarily. But you might start
> publishing again 20 minutes later or whatever. So why delete the node
> (along with all its subscriptions) only to re-create it so soon?
>
> Peter
>

Agreed. Deleting and recreating nodes probably creates (server) overhead
I didn't really think about. Probably retracting the node (which is what
Miranda, Psi and Gajim SVN do) is equally bad and has the added penalty
of not being required for PEP.
On the other hand defining empty states (or a <mu /> element as Dave
Cridland suggested) doesn't sound right to me either, because User
Tune/Nickname/Mood/Activity/Geolocation/Weather/Clothing as I understand
it mainly defines a generic XML format to express "things".
Outside the context of PEP lack of information in this XML is useless.
The XML just wouldn't be present in the first place. BUT in PEP this
requires deleting/retracting the node...

Another thought: Delete nodes, BUT make sure it's a rare case.
Normally, as you point out, people who published information will do it
again. The node should only be deleted if they really don't want to
publish any information.
When this is the case is different for every "User *", but I think the
XEPs can be defined in a way that it is a rare case that people don't
want to publish any information.

So let's look at this per XEP:

User Tune:
normally people will listen to music or not and publish the song or a
stopped state accordingly. The case that people are secretly listening
to a song is probably relatively rare.

User Mood:
This has the problem that not every possible mood is present. Adding a
"something else" option might be a solution here (Or is it valid to only
send <text />? I think clients don't allow it...). I personally wouldn't
publish my mood at all (maybe in rare cases) because I think it's to
personal. People who decide to publish it will probably do it all the time.

User Activity:
Same as User Mood IMHO. A "doing something else" state would help .

User Geolocation:
Defining a <private /> state would help. Admittedly this is very similar
to providing no information at all which is what I didn't want to
define, but IMHO this privacy statement is still a bit different from no
information.

User Nickname:
People who don't want a nickname any more will probably not want one for
a longer period of time.

I think if this changes were made nodes wouldn't be deleted to often,
but still could be if no information is to be published, in which case
deleting the node is the "right thing" to do IMHO.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINsXp0JXcdjR+9YQRAt3dAJ45RCQIH2jYAQEzIbthab P9P4vk3gCgh6/N
kBpvWIDK+VonRVKiym3d3jw=
=Qme5
-----END PGP SIGNATURE-----

[Peter Saint-Andre]

On 05/23/2008 7:26 AM, Florian Zeitz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> It seems rather messy to delete the node and then re-create it all the
>> time. For example, lots of geolocation services enable you to specify
>> certain locations that are private. So when you move to a private
>> location, you want to stop publishing temporarily. But you might start
>> publishing again 20 minutes later or whatever. So why delete the node
>> (along with all its subscriptions) only to re-create it so soon?
>>
>> Peter
>>
>
> Agreed. Deleting and recreating nodes probably creates (server) overhead
> I didn't really think about. Probably retracting the node (which is what
> Miranda, Psi and Gajim SVN do) is equally bad and has the added penalty
> of not being required for PEP.
> On the other hand defining empty states (or a <mu /> element as Dave
> Cridland suggested) doesn't sound right to me either, because User
> Tune/Nickname/Mood/Activity/Geolocation/Weather/Clothing as I understand
> it mainly defines a generic XML format to express "things".
> Outside the context of PEP lack of information in this XML is useless.
> The XML just wouldn't be present in the first place. BUT in PEP this
> requires deleting/retracting the node...
>
> Another thought: Delete nodes, BUT make sure it's a rare case.
> Normally, as you point out, people who published information will do it
> again. The node should only be deleted if they really don't want to
> publish any information.
> When this is the case is different for every "User *", but I think the
> XEPs can be defined in a way that it is a rare case that people don't
> want to publish any information.
>
> So let's look at this per XEP:
>
> User Tune:
> normally people will listen to music or not and publish the song or a
> stopped state accordingly. The case that people are secretly listening
> to a song is probably relatively rare.
>
> User Mood:
> This has the problem that not every possible mood is present. Adding a
> "something else" option might be a solution here (Or is it valid to only
> send <text />? I think clients don't allow it...). I personally wouldn't
> publish my mood at all (maybe in rare cases) because I think it's to
> personal. People who decide to publish it will probably do it all the time.
>
> User Activity:
> Same as User Mood IMHO. A "doing something else" state would help .
>
> User Geolocation:
> Defining a <private /> state would help. Admittedly this is very similar
> to providing no information at all which is what I didn't want to
> define, but IMHO this privacy statement is still a bit different from no
> information.
>
> User Nickname:
> People who don't want a nickname any more will probably not want one for
> a longer period of time.
>
> I think if this changes were made nodes wouldn't be deleted to often,
> but still could be if no information is to be published, in which case
> deleting the node is the "right thing" to do IMHO.

Those proposals are fine with me.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> On 05/23/2008 7:26 AM, Florian Zeitz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> It seems rather messy to delete the node and then re-create it all the
>>> time. For example, lots of geolocation services enable you to specify
>>> certain locations that are private. So when you move to a private
>>> location, you want to stop publishing temporarily. But you might start
>>> publishing again 20 minutes later or whatever. So why delete the node
>>> (along with all its subscriptions) only to re-create it so soon?
>>>
>>> Peter
>>>
>> Agreed. Deleting and recreating nodes probably creates (server) overhead
>> I didn't really think about. Probably retracting the node (which is what
>> Miranda, Psi and Gajim SVN do) is equally bad and has the added penalty
>> of not being required for PEP.
>> On the other hand defining empty states (or a <mu /> element as Dave
>> Cridland suggested) doesn't sound right to me either, because User
>> Tune/Nickname/Mood/Activity/Geolocation/Weather/Clothing as I understand
>> it mainly defines a generic XML format to express "things".
>> Outside the context of PEP lack of information in this XML is useless.
>> The XML just wouldn't be present in the first place. BUT in PEP this
>> requires deleting/retracting the node...
>>
>> Another thought: Delete nodes, BUT make sure it's a rare case.
>> Normally, as you point out, people who published information will do it
>> again. The node should only be deleted if they really don't want to
>> publish any information.
>> When this is the case is different for every "User *", but I think the
>> XEPs can be defined in a way that it is a rare case that people don't
>> want to publish any information.
>>
>> So let's look at this per XEP:
>>
>> User Tune:
>> normally people will listen to music or not and publish the song or a
>> stopped state accordingly. The case that people are secretly listening
>> to a song is probably relatively rare.
>>
>> User Mood:
>> This has the problem that not every possible mood is present. Adding a
>> "something else" option might be a solution here (Or is it valid to only
>> send <text />? I think clients don't allow it...). I personally wouldn't
>> publish my mood at all (maybe in rare cases) because I think it's to
>> personal. People who decide to publish it will probably do it all the time.
>>
>> User Activity:
>> Same as User Mood IMHO. A "doing something else" state would help .
>>
>> User Geolocation:
>> Defining a <private /> state would help. Admittedly this is very similar
>> to providing no information at all which is what I didn't want to
>> define, but IMHO this privacy statement is still a bit different from no
>> information.
>>
>> User Nickname:
>> People who don't want a nickname any more will probably not want one for
>> a longer period of time.
>>
>> I think if this changes were made nodes wouldn't be deleted to often,
>> but still could be if no information is to be published, in which case
>> deleting the node is the "right thing" to do IMHO.
>
> Those proposals are fine with me.

What about defining the following in XEPs 107, 108, etc.?

<iq type='set'
from='juliet (AT) capulet (DOT) lit/ca486eba-0f9a-11dc-8835-000bcd821bfb'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/mood'>
<item>
<mood xmlns='http://jabber.org/protocol/mood'/>
</item>
</publish>
</pubsub>
</iq>

<iq type='set'
from='juliet (AT) capulet (DOT) lit/ca486eba-0f9a-11dc-8835-000bcd821bfb'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/activity'>
<item>
<activity xmlns='http://jabber.org/protocol/activity'/>
</item>
</publish>
</pubsub>
</iq>

That is just like what we do in User Tune.

Peter

--
Peter Saint-Andre
https://stpeter.im/