Alexis <flexibeast@gmail.com> writes:

> Daimrod <daimrod@gmail.com> writes:
>
>> So, as you said, we would need to define and document a specification
>> for org-contacts. And we need to be clear from the beginning about
>> what it can do and what it can not do. For example, it is unlikely
>> that org-contacts will be a 1:1 mapping with the vCard format in its
>> current form because vCard properties can have values.
>>
>> e.g.
>> PROP1;PROP2=VAL:FOO BAR
>>       ^^^^^^^^^
>
> Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which
> is how my Android phone vCard-exports a mobile number) to
> e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like
> e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just
> brainstorming, however. :-)

Sure, but then how would we define the map? with a fixed set of rules?
with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL")
("EMAIL_WORK" -> "EMAIL;TYPE=work")))?

I'm not saying that it's impossible nor that we shouldn't do it but that
we need to think about it first. :)

>> An approach would be to keep using properties whenever it's possible
>> to keep the format simple when possible and use subtree instead of
>> properties when necessary.
>>
>> e.g.
>> #+BEGIN_SRC org
>>   ,* Contact Name
>>   ,** PHONE
>>      :PROPERTIES:
>>      :TYPE:     WORK
>>      :END:
>>   - num1
>>   - num2
>> #+END_SRC
>>
>> But then we would need a special property to indicate that a subtree
>> is a contact and ignore subtree without this property (just like it
>> does with the EMAIL property ATM).
>>
>> #+BEGIN_SRC org
>>   ,* Contact Name
>>     :PROPERTIES:
>>     :TYPE:     org-contacts
>>     :END:
>>
>>   ,** PHONE
>>      :PROPERTIES:
>>      :TYPE:     WORK
>>      :END:
>>   - num1
>>   - num2
>> #+END_SRC
>>
>> And of course it would be nice if we could keep as much compatibility
>> with the current format :)
>
> Well, to me this looks broadly similar to what Esben has proposed:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html
>
> Although i like the idea of such a format in principle, my concern (as i
> noted in my reply to Esben) is that this might require a substantial
> modification of org-contacts.el, both to accommodate this format and to
> ensure backwards-compatibility. If this is indeed the case, and someone
> else is willing to commit to being the lead on undertaking that work,
> then i'll certainly support that work and write relevant MobileOrg code
> to work with both the new and old formats. Otherwise, from my
> perspective of wanting to simply add some more fields and be able to
> transfer contact details between MobileOrg and my phone's Contacts
> system, it's more than i'm willing to take on at this point.

Well, if people are willing to help, I'll see if I can come up with a
proposal.

-- 
Daimrod/Greg