Subject: [Simple] Free text in presence documents

From: Rohan Mahy <[email-masked]>
Date: Mon, 25 Apr 2005 18:09:03 -0700

Hi,

I'd like to make some comments on the rather casual sprinkling of free 
text elements in PIDF and its extensions. In part I would like to 
clarify and refine my earlier point about the proliferation of note 
text.

1) It may come as a surprise to some of you that I believe that we need 
an element which contains a free-text alternative or alternatives to 
siblings which are members of an explicit enumeration.  However, I 
think the semantics need of such an element need to be really crisp or 
it loses value. I also think this has very different semantics than the 
current <note> element in basic PIDF.  I will use <text> for this 
purpose in my example.  Whatever we call this element, I feel very 
strongly that it should have the semantics of its parent.  For example, 
Juggling chainsaws is an activity, which is not specifically included 
in any standard enumeration.**  In other words, my hypothetical <text> 
element has an "is-a" relationship with its parent element.

<person>
   <status>
     <basic>closed</basic>
   </status>
   <rp:activities>
     <text>Juggling chainsaws</text>
   </rp:activities>
</person>

Contrast this with the following example from the RPIDs draft:

<rp:mood>
   <rp:happy/>
   <note>I got my paycheck!</note>
</rp:mood>

"I got my paycheck" is not a mood; it is a statement.  While it's nice 
that you got paid, that statement doesn't belong here IMO.

2) ** I think we should try to avoid having both free-text and 
enumerations which have the same semantics. However, some of the 
enumerations might get extended.  In that case the implementor might 
want to provide a free text alternative to a new element which a 
receiving might not understand.  In that case, I think we want the 
receiver to know the difference between an alternative and an 
additional semantic.  I think we could probably do that by adding an 
attribute of some kind.  For example:

<rp:mood>
   <my:slovenly/>
   <text alt="my:slovenly" xml:lang="en">slovenly</text>
   <text alt="my:slovenly" xml:lang="fr">ralenti</text>
</rp:mood>

3) Of course, we also have the <note> elements in basic PIDF which are 
legal in the <presence> element and in the <tuple> element.  I am 
already getting the same headache I get when I think about parsing SDP 
c-lines.  Implementations have already used the <note> in the 
<presence> element to apply to <tuple> elements with no note of their 
own, and also to imply a note appropriate for a <person> element.  
Yuck!     Now we are talking about introducing a new <note> element 
explicitly for the <person> element and possibly another for the 
<device> element.  What are the semantics of each of these notes?  How 
do I merge these notes?  If one of these a status, a funny saying, 
directions to contact me, or some characteristic of the tuple, person, 
or device?

I think the existing <note> is (or has become) an opaque blob of text 
that users of IM systems expect to be conveyed transparently for a 
specific *service*.  I do not think it applies to a <person> element 
because the semantics of the blob are not known.

All this talk about separate status like "running out of battery power" 
for your device is nice in theory, but we should call them something 
else. I also don't think we will be able to agree on crisp semantics, 
in part because I don't think these extensions are a core part of the 
data model.

Here some examples of notes I have seen at various times.  Where do 
each of these belong?  How do I compose these?  I don't know about 
others, but I won't even try.  I'll present/render each one under the 
service that provided the note.

<note>Purple Califlower!</note>
<note>at home +1 408 555 1212</note>
<note>At Lunch</note>
<note>bork, bork, bork</note>
<note>Away</note>
<note>Stepped Out</note>
<note>Ah, home</note>
<note>Lovestad 08:00 GMT +2</note>
<note>http://ln-s/983/</note>

So, while I am not opposed to additional free-text fields, they should 
have specific semantics and they should have a different name than the 
current <note> element, which has become useless for automata.

thanks,
-rohan

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Apr 2005 22:20:42 -0400

>   <note>I got my paycheck!</note>

The example is borrowed from the Jabber docs, if I recall correctly, 
which have a similar mechanism.

> that you got paid, that statement doesn't belong here IMO.

There are at least two uses of such free text:

(1) Explaining the background for an enumeration. ("I got my paycheck!")

(2) Providing additional values for an enumeration which are not 
captured by the existing list ("Juggling chainsaws")

Both are of value, I believe. I don't think it is particularly helpful 
to try to create two types of elements for this, as this seems unlikely 
to be observed by users typing in this information. The likely 
consequence of facilitating (2) is to essentially make that the 
enumeration extension mechanism for software.

> receiver to know the difference between an alternative and an additional 
> semantic.  I think we could probably do that by adding an attribute of 
> some kind.  For example:
> 
> <rp:mood>
>   <my:slovenly/>

This might be interesting, but seems awfully complex for this case. How 
likely is it that we'll see implementations of this?

> c-lines.  Implementations have already used the <note> in the <presence> 
> element to apply to <tuple> elements with no note of their own, and also 
> to imply a note appropriate for a <person> element.  Yuck!     Now we 
> are talking about introducing a new <note> element explicitly for the 
> <person> element and possibly another for the <device> element.  What 
> are the semantics of each of these notes?  How do I merge these notes?  
> If one of these a status, a funny saying, directions to contact me, or 
> some characteristic of the tuple, person, or device?
> 

The only justification for a generic <person> note, for example, is to 
explain things that are not captured by any of the existing RPID 
elements. For a contrived example, suppose we have not yet introduced a 
'visual appearance' element, so something like

<note>Bad hair day - please don't ask for video.</note>

will be a <person>-specific note.

This clearly describes a person, not a device or a service.

> else. I also don't think we will be able to agree on crisp semantics, in 
> part because I don't think these extensions are a core part of the data 
> model.
> 
> Here some examples of notes I have seen at various times.  Where do each 
> of these belong?  How do I compose these?  I don't know about others, 
> but I won't even try.  I'll present/render each one under the service 
> that provided the note.

Or simply show all of them if I need to compose multiple <person> elements.

The whole point of free text is to allow for a reality that can't easily 
be classified into neat enumerations.

> current <note> element, which has become useless for automata.

<notes> are always going to be useless for automata. That's why they are 
there...

I agree that having notes/free-text close to elements that they describe 
is useful, since it makes filtering, for example, easier (avoids 
information leakage) and allows better context-appropriate rendering 
(e.g., showing a balloon text over the activities icon).

Henning

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 25 Apr 2005 19:54:23 -0700

On Apr 25, 2005, at 19:20, Henning Schulzrinne wrote:

>> "I got my paycheck" is not a mood; it is a statement.  While it's 
>> nice that you got paid, that statement doesn't belong here IMO.
>

I understand that a *human* recognizes this as a justification, but its 
just not relevant semantically in the context of the mood element.  
(The creation of which is intended to be useful to computer programs).  
Semantically, the justification is just a statement about the person.  
Somebody should put this as a textual element elsewhere.  (see my 
comment about <aboutMe> below)

> to try to create two types of elements for this, as this seems 
> unlikely to be observed by users typing in this information. The 
> likely consequence of facilitating (2) is to essentially make that the 
> This might be interesting, but seems awfully complex for this case. 
> How likely is it that we'll see implementations of this?

do you care about being able to make a distinction between additional 
values and alternative values?

additional value:
<rp:activities>
   <travel/>
   <custom>brushing teeth</custom>
</rp:activities>

alternative value:
<rp:activities>
   <meal/>
   <custom xml:lang="fr">dejeuner</custom>
</rp:activities>

>> 3) Of course, we also have the <note> elements in basic PIDF which 
>> are legal in the <presence> element and in the <tuple> element.  I am 
>> already getting the same headache I get when I think about parsing 
>> SDP c-lines.  Implementations have already used the <note> in the 
>> <device> element.  What are the semantics of each of these notes?  
>> How do I merge these notes?  If one of these a status, a funny 
>> saying, directions to contact me, or some characteristic of the 
>> tuple, person, or device?
> elements. For a contrived example, suppose we have not yet introduced 
> a 'visual appearance' element, so something like
>

Sure.  But I don't think we should call it a <note> element.  It's the 
<aboutMe> element or something.  This would make it much more clear for 
implementors that these things are different.  This thing can also be 
of type Note_t, but it would have different semantics than other 
elements of the same type.

>> All this talk about separate status like "running out of battery 
>> power" for your device is nice in theory, but we should call them 
>> something else. I also don't think we will be able to agree on crisp 
>> semantics, in part because I don't think these extensions are a core 
>> part of the data model.
> The whole point of free text is to allow for a reality that can't 
> easily be classified into neat enumerations.

but the whole point of writing a schema is to come up with crisp 
semantics so real programmers can write real programs that have a hope 
of parsing, rendering, composing, sending this information.  Bonus 
points if the parsing and sending actual results in interop.  ;-)

>> So, while I am not opposed to additional free-text fields, they 
>> should have specific semantics and they should have a different name 
>> than the current <note> element, which has become useless for 
>> automata.
>
> <notes> are always going to be useless for automata. That's why they 
> are there...

you always need a relief valve / garbage pit.  We need to have one, but 
we only need *one*.  <note> has become that garbage pit.  We don't need 
to create a proliferation of them.

thanks,
-rohan

> I agree that having notes/free-text close to elements that they 
> describe is useful, since it makes filtering, for example, easier 
> (avoids information leakage) and allows better context-appropriate 
> rendering (e.g., showing a balloon text over the activities icon).
>
> Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Apr 2005 23:29:11 -0400

Rohan Mahy wrote:

> just not relevant semantically in the context of the mood element.  (The 

Indeed - it explains the mood to the human observer.

> creation of which is intended to be useful to computer programs).  

Part (or for RPID, most of it) is display to humans. Computer programs 
generally don't appreciate moods as such.

> comment about <aboutMe> below)

In general, I hope we agree that it is useful to be able to annote 
elements, as that provides semantic association that collecting this in 
one big blob loses. As I noted earlier, this also makes it a lot easier 
to filter out information based on context. If I don't want to show the 
mood element, removing the associated annotation is a lot easier if it 
is part of that element rather than all collected in some general 
annotation element.

>   <custom xml:lang="fr">dejeuner</custom>

Not particularly. I very much doubt that user interfaces would expose 
this level of detail.

> implementors that these things are different.  This thing can also be of 
> type Note_t, but it would have different semantics than other elements 
> of the same type.

I don't particularly care about the element tag. I don't see the harm of 
calling it a note - this seems to be universally understood as content 
to be rendered to humans, annotating the enclosing element.

> points if the parsing and sending actual results in interop.  ;-)

The semantics of <notes> or whatever you call them are clear:

- No attempt at automated processing

- Render close to the enclosing element, possibly in some way that 
indicates an annotation (mouse-over, alt-text, etc.)

- Remove if enclosing element is removed.

- Compose by concatenation within each element.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Apr 2005 10:04:46 -0400

Interesting discussion.

I agree with Rohan about the value of associating semantics with 
additional elements. However I don't think the examples really 
accomplish that. You may believe that

Adds a new semantic element to <activities>, but other than knowing it 
is is a different element, what semantic is the watching UA supposed to 
associate with it?

I think it would make more sense to associate free text with an existing 
defined enumeration element. The interpretation would be one of 
specialization:

	<busy text="brushing teeth"/>

This element may be semantically treated as simply <busy/>. As long as 
each enumeration as at least one sufficiently vague element there should 
always be something reasonable to attach your refinement to.

	Paul

Henning Schulzrinne wrote:
> Rohan Mahy wrote:
> 
>>
> 
>> I understand that a *human* recognizes this as a justification, but 
>> its just not relevant semantically in the context of the mood 
>> element.  (The 
> 
> 
>> <aboutMe> element or something.  This would make it much more clear 
>> for implementors that these things are different.  This thing can also 
>> be of type Note_t, but it would have different semantics than other

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 26 Apr 2005 16:44:53 +0200

Interesting discussion indeed. It took a couple of reads and sometime 
to understand what Rohan is trying to do, but I get it now :)

I agree with Rohan that the semantics behind the <note> elements that 
exist today and the proposed ones for <person> and <device> are vague. 
I also agree that they need to be renamed to make it easier for 
implementers to understand what purpose they serve. But the catch is 
that those things require human input. I'm not talking about the human 
implementers. I am talking about end users. You can rename the <note> 
element to <aboutme>, but that will only help implementers name the 
label next to the edit box a little better. That's about it. We cannot 
control what the end user will put there.

I don't quite understand the multi language thing. Are you proposing 
that the <text> element be repeated in different languages? In that 
case, how does a compositor know which one the watcher wants?

Paul, for your suggestion below, do you mean that all existing <mood>s 
need that text attribute? Isnt it a bit too much?

/Hisham

On Apr 26, 2005, at 4:04 PM, Paul Kyzivat wrote:

> is is a different element, what semantic is the watching UA supposed 
> to associate with it?
>
> I think it would make more sense to associate free text with an 
> existing defined enumeration element. The interpretation would be one 
> of specialization:
>
> each enumeration as at least one sufficiently vague element there 
> should always be something reasonable to attach your refinement to.
>
> 	Paul
>
>> Part (or for RPID, most of it) is display to humans. Computer 
>> programs generally don't appreciate moods as such.
>>> Semantically, the justification is just a statement about the 
>>> person.  Somebody should put this as a textual element elsewhere.  
>>> (see my comment about <aboutMe> below)
>> elements, as that provides semantic association that collecting this 
>> in one big blob loses. As I noted earlier, this also makes it a lot 
>> easier to filter out information based on context. If I don't want to 
>> show the mood element, removing the associated annotation is a lot 
>> easier if it is part of that element rather than all collected in 
>> some general annotation element.
>>> do you care about being able to make a distinction between 
>>> additional values and alternative values?
>>>
>>> additional value:
>>> <rp:activities>
>>>   <travel/>
>>> Sure.  But I don't think we should call it a <note> element.  It's 
>>> the <aboutMe> element or something.  This would make it much more 
>>> clear for implementors that these things are different.  This thing 
>>> can also be of type Note_t, but it would have different semantics 
>>> than other elements of the same type.
>> I don't particularly care about the element tag. I don't see the harm 
>> of calling it a note - this seems to be universally understood as 
>> content to be rendered to humans, annotating the enclosing element.
>>> semantics so real programmers can write real programs that have a 
>>> hope of parsing, rendering, composing, sending this information.  
>>> Bonus points if the parsing and sending actual results in interop.  
>>> ;-)

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Apr 2005 10:15:06 -0700

> Indeed - it explains the mood to the human observer.

I disagree that it explains any more to the human observer *here* under 
the mood element than it would in a generic textual element hanging 
under person.

> generally don't appreciate moods as such.

humans are not directly reading the XML document.  Computer programs 
will read the XML and render the contents as best they can.  Having a 
proliferation of "annotations" each in different parts of the XML 
document are unlikely to be of any more value to a human, but a 
proliferation of text fields makes it difficult for computer programs 
to know how to render the information.  Even for devices with a 
relatively large display area, there are human factors issues which 
prevent programs from displaying annotations all over the place.

> easier if it is part of that element rather than all collected in some 
> general annotation element.

I absolutely disagree. Tons of human factors studies show that 
annotating arbitrary elements with arbitrary text is NOT generally 
useful for humans, even if the computer program could figure out how to 
display the information in a sensible way.

> Not particularly. I very much doubt that user interfaces would expose 

This is not just an issue for display, it is also an issue for 
compositing.
The difference from a UI perspective seems pretty easy to display.  
Take a french user interface displaying:

voyager, "brushing teeth"   or  just  "dejeuner"

I'm not sure what you imagine a UI would display for activities, but I 
am imagining either a list of words, or a set of icons (which would 
effectively exclude custom strings not known by the UI.

> content to be rendered to humans, annotating the enclosing element.

that's not the semantics of the current <note> element.  A <note> under 
the root <presence> element actually "annotates" the status or a 
characteristic of (possibly many) <tuple> elements.

> - Compose by concatenation within each element.

I don't agree that concatenation is appropriate here.  For example, 
merging these two by concatenation is not likely what the user 
intended.

<person>
   <activies>
     <note>asleep</note>
   </activities>
</person>

<person>
   <activities>
     <note>at the dentist</note>
   </activities>
</person>

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Apr 2005 10:53:09 -0700

> case, how does a compositor know which one the watcher wants?

If the human user types something in a small number of languages, you 
can provide all of them and the receiver can display the best one, but 
only if it knows the difference between an alternative and an 
additional text element ;-)

thanks,
-rohan

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 26 Apr 2005 20:32:55 +0200

> additional text element ;-)

So we need to group the alternatives or have an id for them.

Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Apr 2005 17:51:18 -0400

Hisham Khartabil wrote:
> Interesting discussion indeed. It took a couple of reads and sometime to 
> understand what Rohan is trying to do, but I get it now :)
> 
> exist today and the proposed ones for <person> and <device> are vague. I 
> also agree that they need to be renamed to make it easier for 

Well, at least the way I showed it I guess it would require that, which 
would be annoying at this late date.

There are other ways the same thing could be achieved. Perhaps:

	<new-activity specializes="busy">Brushing Teeth</new-activity>

Paul

>>>> Bonus points if the parsing and sending actual results in interop.  ;-)
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Apr 2005 18:05:20 -0400

Rohan Mahy wrote:

> This is not just an issue for display, it is also an issue for compositing.
> The difference from a UI perspective seems pretty easy to display.  Take 
> a french user interface displaying:
> 

Rohan - I don't understand what you are proposing here. You seem to be 
showing two alternative meanings for the same extension syntax and 
suggesting to adopt them both.

The defintion as alternative value, at least for translations, seems 
both unworkable and unnecessary to me as a way to translate predefined 
values:

- unworkable because I see nothing in the syntax you show that binds the 
alternative to its primary.

- unnecessary because the whole point of using standard enumerations is 
that the names are just labels for semantics - they aren't necessarily 
display names. The French UI is free to represent <meal> as "dejeuner" 
if it wants. (And the English UI can represent <meal> as "lunch".)

The point of my proposal (with the new syntax in my response to Hisham) 
would be to permit you to define

	<new-activity specializes="meal">dejeuner</new-activity>

Then a UI that wants to can display the text for this, and/or it can 
treat it exactly the same as <meal> (e.g. display a knife&fork icon.)

In all cases, at least the new activity can be interpretted as some 
element with predefined semantics.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Apr 2005 22:06:23 -0400

> the mood element than it would in a generic textual element hanging 

No. Even in this contrived example, the sentence

"I'm getting my paycheck!"

has a different meaning when it appears next to mood 'happy' compared to 
  a location reference. See also the item about filtering.

mputer programs to
> know how to render the information.  Even for devices with a relatively 
> large display area, there are human factors issues which prevent 
> programs from displaying annotations all over the place.

As noted earlier, it is actually easier that way, e.g., through 
mouse-overs, to render such annotations that are close to the element 
that they describe.

> display the information in a sensible way.

I'm curious: Any pointers to such studies?

>     <note>at the dentist</note>

This is actually a good example why a simple blob is not a good idea. In 
this case, composition would select one of the activities (if more 
credible), including the annotation. A single blob would not be 
selectable in that way.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Apr 2005 20:52:51 -0700

On Apr 26, 2005, at 19:06, Henning Schulzrinne wrote:

> Rohan Mahy wrote:
>
>> I disagree that it explains any more to the human observer *here* 
>> under the mood element than it would in a generic textual element 
>> hanging under person.
>
> has a different meaning when it appears next to mood 'happy' compared 
> to  a location reference. See also the item about filtering.

what different meaning?

> mputer programs to
>> know how to render the information.  Even for devices with a 

can you have a note element in a mood with no moods enumerated?  what 
about multiple textual elements within an activities element?  is that 
ok?  how do you provide indication to the user that they can get more 
information by mousing-over?

>> useful for humans, even if the computer program could figure out how 
>> to display the information in a sensible way.
>

I'll try to dig some up.

> This is actually a good example why a simple blob is not a good idea. 
> In this case, composition would select one of the activities (if more 

I think you would judge the credibility of the entire person, tuple, or 
device, and disregard the entire thing is it is not credible. If the 
source isn't credible why would you keep any of the information that 
you discredited?

thx,
-r