On Thu, 2014-05-01 at 16:53 +0200, Lukas Zeller wrote:
> Hello Patrick,
>
> On 30.04.2014, at 19:10, Patrick Ohly <[email protected]> wrote:
>
> >> What you have here is probably the most elaborate profile ever
> >> specified for libsynthesis :-) , but I see no reason why it should not
> >> work once the <position> is correct.
> >
> > That's what I had tried earlier. It leads to the situation where the
> > labels of independent properties overwrite labels of other, earlier
> > properties.
>
> What do you mean by "independent" properties?
For example, ADR and TEL are independent in the sense that their values
are stored in different field arrays. Sharing the LABEL field for the
new parameter creates a dependency (or risk of collision) that did not
exist before.
> > That's because the position checking seems to focus
> > exclusively on property values and ignores property parameters.
>
> Yes.
>
> Somehow I don't see how a label parameter value can get stored without
> also writing an associated property value.
>
> Only when using the grouped tag mode with a separate X-ABLabel
> property, it might happen that you only have the label, but not (yet)
> the values, depending on the order of the group members in the vCard.
> Only if you mix both variants in the input vCard, I can imagine
> something like the following could go wrong:
>
> A.X-ABLabel:labelA
> TEL;X-ABLabel=labelTel:123456789
> A.TEL:987654321
>
> In this case there is a label-only situation after the first line is
> parsed. When the second line is parsed, it will overwrite the first
> label (because it does not check the parameter array for being empty
> at that index), so labelA would be lost.
It's simpler.
TEL;X-ABLabel=labelTel:123456789
ADR;X-ABLabel=labelAdr:xxx
stores only the second label at position #0
=> LABEL = [ 'labelAdr' ]
That's because the code which checks where to store the ADR value does
not check whether the LABEL at the position is available.
There's another problem:
TEL:123456789
ADR;X-ABLabel=labelAdr:xxx
A simplistic check "LABEL[0] empty" will accept position #0 for ADR. But
doing so will add the labelAdr also to the TEL, which was previously
created at position #0.
That means that the check has to be "LABEL[0] does not exist".
> > Similar to "for (sInt16 e=0; e<aPropP->numValues; e++) {" the code would
> > also need to iterate over aPropP->parameterDefs.
>
> Yes.
This helped, but so far I have only implemented the too simplistic
check.
I noticed another problem with the "use X-ABLabel parameter" approach:
storing complex strings (spaces, quotation marks) in a parameter value
is harder. The EDS vCard parser gets it wrong and fails to parse:
X-ABRELATEDNAMES;X-ABLabel=domestic partner:domestic partner
That is valid according to http://tools.ietf.org/html/rfc2425#page-5
because the space is a SAFE-CHAR and thus may appear in a ptext, but the
EDS parser does not expect the space. To work around this, we could
voluntarily quote the string even though it is not required.
Now, the conceptual problem with "X-ABLabel parameter" is that a quoted
string cannot contain double quotes. It is probably rare that a user
enters double quotes as part of a label, but it cannot be ruled out
either. Line breaks are also only allowed in property values and not
parameter values.
I'm undecided now how to proceed. Simplify X-ABLabel property values so
that they can be stored as parameter? Use the more complex X-ABLabel
property and grouping? Bummer.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
