[Freeassociation-devel] Should we allow invalid rfc2445 to be output?

[crass at berlios.de]

Currently, "RDATE;VALUE=DATE-TIME:19970101T120000/PT3H10M15S" can be
output by the following code:

    struct icalperiodtype period;
    struct icaldatetimeperiodtype dtp;
    icalproperty *p;
    const char* str;

    period.start = icaltime_from_string("19970101T120000");
    period.end = icaltime_null_time();
    period.duration = icaldurationtype_from_string("PT3H10M15S");
    
    dtp.time = icaltime_null_time();
    dtp.period = period;
    p = icalproperty_new_rdate(dtp);
    icalproperty_add_parameter(p,icalparameter_new_value(ICAL_VALUE_DATETIME));
    str = icalproperty_as_ical_string(p);

where str = "RDATE;VALUE=DATE-TIME:19970101T120000/PT3H10M15S\r\n"

Being able to create an ical property string with a value parameter
different than the type of the actual value was introduced in
icalproperty_get_value_kind in r772 with the comment "merging in the
KDEPIM deltas. Silencing many warnings, make many const, and some other
neat fixes / features added."  It seems like libical should be smarter
than this and that's what is expected by the failing regression tests
in regression.c function "test_rdate".

So, should we allow invalid ical output?  specifically in this case
output which will not be able to be parsed by our parser?

Should we have the expectation that isequal(comp,
icalparser_parse_string(icalcomponent_as_string(comp))?

If libical should be smarter, I think we'll need more of a type system
for knowing what can be converted to what.  For instance, it seems
acceptable to have an INTEGER be output with VALUE=FLOAT.

One reason for wanting libical to be smarter is that it would prevent a
libical programmer from having to remove the VALUE parameter from a
property whose value is being changed to a value of a type different
than the original.  This was actually originally the way libical
worked, except that it basically ignored the VALUE parameter.  I'm
saying we need to only selectively ignore it, and there are case where
we must use it.

Glenn