[Kde-pim] [RFC] ContactGroup storage format

[Ingo Klöcker]

On Tuesday 04 December 2007, Kevin Krammer wrote:
> Hi Tobias,
>
> On Tuesday 04 December 2007, Tobias Koenig wrote:
> > On Mon, Nov 26, 2007 at 01:23:16PM +0100, Kevin Krammer wrote:
> > > As far as I understand it is bascially a formalized description
> > > of the current distribution list items, right?
> >
> > Yes, but it also describes how the distribution lists can be stored
> > as xml document.
>
> Right :)
>
> > > I am unsure though if generalizing the name to ContactGroup but
> > > still keeping the e-mail aspect as the distribution criteria
> > > won't be confusing or make future extensions awkward.
> >
> > So what's the difference between a group of contacts and a
> > distribution list? ;)
>
> A contact group groups contacts for whatever purpose, a distribution
> list groups them for distributing something to them.
>
> From my point of view a distribution list is a spezialisation of a
> contact group, but I guess the other forms for grouping are usually
> done through tagging, right?

There's a subtle but important difference between a mere group of 
contacts and a distribution list. A group of contacts is just a list of 
contact ids, while a distribution list is a list of ( contact id 
optionally plus email address to be used instead of the preferred 
address ).

Sure, a distribution list can also be considered as a list of ( contact 
id plus meta data ), but is there really a use case for such lists? If 
yes, then I suggest to use something like

<contactgroup>
  <id>abcd</id>
  <name>Video Night</name>

  <entry>
    <id>contact1</id>
  </entry>
  <entry>
    <id>contact2</id>
    <contactdata>
      <email>contact2alternative at example.com</email>
    </contactdata>
  </entry>
</contactgroup>

where everything in <contactdata> would overwrite the values that would 
otherwise be taken from the contact's data. The XML format inside 
<contactdata> should be the same XML format that is also used for an 
XML-based vcard-alternative. There's no need to re-invent yet another 
XML format for storing contact data. Since Kolab does already specify 
such an XML format I suggest looking into this.

To prevent inconsistencies/outdated data in <contactdata> it could make 
sense to use back-references (via uids) to specific entries in the 
contact's data similar to the usage of indices below.

For example the contact's data could be:
<contact>
  <id>contact1</id>
  <addresses>
    <address>
      <id>addressY</id>
      <type>home</type>
      <street>some street</street>
      [...]
    </address>
    <address>
      <id>addressX</id>
      <type>home</type>
      <street>another street</street>
      [...]
    </address>
  </addresses>
</contact>

with addressY being somehow marked as the preferred address. And then a 
possible entry in the contact group could be:

  <entry>
    <id>contact1</id>
    <contactdata>
      <addresses>
        <address type="ref">addressX</address>
      </addresses>
    </contactdata>
  </entry>

I hope you get the idea.


> > That data structure is mainly used for grouping contacts, sending
> > mails to multiple persons and using the lists as base for form
> > letters in kword. As you are free to fill the list with references
> > to contacts only, where the contacts have all fields set, it can be
> > used for everything.
>
> Hmm.
> I though maybe there is a possibility not to require email for the
> ContactData part, e.g. allow an entry with a FAX number in a list of
> FAX receipients, and in the case of ContactReference maybe something
> like "type of address" (e.g. email, home address, work adress) and
> "index of address" (if a type can have more than one entry)
>
> A bit like
>
> <contactgroup>
>   <id>abcd</id>
>   <name>Video Night</name>
>
>   <contactReference>
>     <id>xyz1</id>
>     <email>0</email> <!-- preferred email -->
>   </contactReference>
>
>   <contactReference>
>     <id>xyz2</id>
>     <email>1</email> <!-- second email -->

Indices are evil since they are no uids. In the case of email addresses 
I would use the actual email address instead of an index or a uid as it 
is done now.


>   </contactReference>
> </contactgroup>
>
> Or for print
> <contactgroup>
>   <id>abcd</id>
>   <name>Birthday Party</name>
>
>   <contactReference>
>     <id>xyz1</id>
>     <address type="home">1</address> <!-- non-main home address, e.g
> student at holiday location (parent's home probably) -->
>   </contactReference>
>
>   <contactReference>
>     <id>xyz2</id>
>     <address type="work">0</email> <!-- main work address -->
>   </contactReference>
> </contactgroup>

For the addresses I would use references instead of indices as described 
above.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20071204/cfe15e28/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/