Re: Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)

[Samuel Wales <samologist@gmail.com>]

FWIW:

It might be the case that we will want to consider the multi-value
property idea and the multi-line property idea together at some point.
 (With or without serialization for the latter.)

I think multi-line properties will eventually be needed (in some form)
in any case for things like org-contacts and they provide a simple way
of allowing more data without imposing semantics.  In other words,
they are usable even if we don't standardize multi-value semantics.

However, Babel and OP both need multi-value properties.

What should a multi-value property be semantically?  Effectively a
vector?  Effectively an alist?  Both are possibilities.

Outside of Babel and OP's case, do we need a layer of semantics on
properties?  Do we want one?  Should we set Babel's interpretation of
multi-value properties in stone for the rest of Org?

Also, should there be an interface to multi-value properties other
than accumulation?  Give me the 3rd value of property?  Give me the
value that matches this string?  Set the 3rd value?  Set (and replace)
the value that matches?

Is accumulation a substitute for multi-line properties?  Or do we want
something nicer for that purpose so that editing and reading are
easier, so that there is no order-dependence of property fields, and
so on?

Just philosophical/design questions.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.