Changes to parsing, validation (and normalization)

[douglm]

I've been thinking that we need a better - more standards driven validator for iCalendar. Many previous validators have disappeared or aren't that good.

I'd like to suggest that we provide better reporting from the parsing process which will go along way towards providing a good validator. Reporting problems doesn't imply failing - just that something isn't fully standards compliant.

For example: the ical4j DTSTAMP will accept all sorts of forms of date-time while the standard only allows UTC (I don't think this is even affected by lenient parsing - it's always lenient).

A validation report would allow non-UTC but flag it as non-standard.

Related to this is normalization - accept non-UTC but emit UTC - I have to do that in my own code as my internal code only allows for UTC.

The first step would be to add some sort of validation report object to the parser API which can be retrieved or is part of the result.

Working through property and component validators would be incremental after that.

[benfortuna]

Agreed. I do recall the initiatives in both validators and test suites, but if they are no longer maintained then I think we can explore this further.

Regarding your points this is how I see the current state of iCal4j:

• Parsing (syntax) - we attempt to report the correct line number for syntax errors. The only relaxed mode currently is allowing superfluous whitespace, but if we need to we could capture all the line numbers where syntax errors are ignored to allow for reporting
• Validation - TBH I've had a few attempts refactoring this, but I think I'm coming to a position where I think this can be almost entirely decoupled from the model (ie. a separate package). So then a model is input to a validator, which allows us to have different validator implementations. For example, default validator is based on rfc5545, iTIP validator uses rules from rfc5546, etc. We could add some form of reporting to these validator implementations.
• Normalisation - typically we do normalisation where possible to apply lenient parsing and strict generation of iCalendar data. Currently there isn't any structured planning of normalisation though, so perhaps that could be improved.

I will try to complete the validation framework separation first as I think that needs the most attention currently.