---- Reported by jingke.zhang@intel.com 2010-04-13 01:47:01 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=3473

This issue is about an improvement of how certain vCard properties are defined
in syncevolution.xml.

Contact chat information should be stored in one field, an array of strings and
one related array with flags that describe what the string is (AIM, MSN, etc.
handle). This has to map to different properties (X-AIM/MSN/...). Currently the
Synthesis engine does not support such a mapping.

URLs are another example (URL, FBURL, CALURL).

Commit dc3944d72226a1e47a409644b07f3c6ee9db1adc "vcard: added support for
missing properties/parameters" solves this by using many different fields. It
would be nice to improve this, but that'll require improvements in the
Synthesis engine. Below a copy of an email discussion with Lukas about this:

From:     Lukas Zeller <luz@synthesis.ch>
To:     Ohly, Patrick <patrick.ohly@intel.com>
Cc:     Beat Forster <bfo@synthesis.ch>, Kukkonen, Jussi
<jussi.kukkonen@intel.com>
Subject:     Re: data modelling
Date:     Fri, 20 Mar 2009 22:26:09 +0000 (23:26 CET)


Hi Patrick,

On Mar 20, 2009, at 16:12 , Patrick Ohly wrote:
> Hmm, is it possible that "hasnot" is only used while parsing?

Yes. It took me a while to recollect the explanation why:


This is because the "has" and "hasnot" mechanism is separate from the parameter
value, you can't mix both. Either a parameter <enum> is "name extending" or it
is a real value. Real values are converted and stored as attributes to the main
value (the URL in your case). Name extending values serve to do the opposite of
what you wanted to do - they are to *dispatch* incoming values of the same
property into different internal fields (like WEB_HOME, WEB_WORK etc.).
So "has" and "hasnot" are not using the value that might be stored for that
parameter AT ALL. The generator just iterates through all defined <position>s,
and generates ALL available instances for each of them, while using the values
referenced by "has" and "shows" as parameter value.


You tried the opposite - *collect* incoming data from multiple properties into
a single array (and dispatch on generation). For that, you'd need each of the
properties involved to "tag" their data when parsing and check the "tag" when
generating.


I think this is a separate thing, and should be handled separately.


My suggestion would be adding a completely separate feature as <tag field="..."
value="..." conversion="..." combine="...">.


This would simply set a predefined value into a field at the time the property
is parsed, otherwise following the same rules as the actual property value
itself. When generating, the value would be checked, and only if it matches for
a given repetition the property would be generated.

So your config would look like (bit 5 now used as flag to denote a regular web
URL):


       <property name="URL">
         <value field="WEB"/>
         <tag field="WEB_FLAGS" value="B5" conversion="multimix"/>
         <parameter name="TYPE" default="yes" positional="no" show="yes">
           <value field="WEB_FLAGS" conversion="multimix" combine=",">
             <enum name="HOME"     value="B0"/>
             <enum name="WORK"     value="B1"/>
             <enum mode="ignore"   value="B2"/> <!-- OTHER -->
             <enum name="PREF"     value="B3"/>
             <enum mode="ignore" name="X-BLOG-URL" value="B4"/>
           </value>
           <position field="WEB" repeat="array" increment="1" minshow="1"
readonly="yes"/>
         </parameter>
       </property>

       <property name="X-EVOLUTION-BLOG-URL">
         <value field="WEB"/>
         <tag field="WEB_FLAGS" value="B4" conversion="multimix"/>
         <position field="WEB" repeat="array" increment="1" minshow="1"
readonly="yes"/>
         <parameter name="TYPE" default="yes" positional="no" show="yes">
           <value field="WEB_FLAGS" conversion="multimix" combine=",">
             <enum name="HOME"     value="B0"/>
             <enum name="WORK"     value="B1"/>
             <enum mode="ignore"   value="B2"/> <!-- OTHER -->
             <enum name="PREF"     value="B3"/>
           </value>
         </parameter>
         <position field="WEB" repeat="array" increment="1" minshow="1"/>
       </property>


Writing this email took around two hours, as I had three other ideas that
turned out, when trying to write them down, either messy or simply not working.
I hope this one is now ok... 


Thinking of it, I realize that that it is very similar to what <subprofile
field="foo" value="bar" ...> already has, only a bit more general. If we decide
to implement that, it could be a good idea to completely generalize the concept
for all levels and allow <tag ...> to appear not only in <property>, but also
in <subprofile> and <parameter>. The old <subprofile ....> syntax could
internally be mapped onto a tag for backwards compatibility.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 680 at https://bugs.meego.com/show_bug.cgi?id=680