Note that we may want to provide a schema for the XML documents
also - see attached for a sample rule XSD (may need some work tho).
Agreed - once we've more closely nailed down what we're looking for, I'll turn that into an XSD. :)
The only other problem I had is that if the test data contains multiple
problems iCal4j may fail on any of them. An example of this was with
reqVersion.xml, whereby tests were missing UID and DTSTAMP properties..
altho these may be a point of contention anyway.. ;) (They aren't required
for relaxed validation in iCal4j)
I think both DDay.iCal and iCal4J will likely need some modifications to correctly handle the standard (and some variations from it). I've had to make some recent changes to DDay.iCal for validation purposes. In this case, UID and DTSTAMP are optional properties, and would be technically allowed to be missing by a strict validation of RFC 2445.
I'm also a bit unclear about the purpose of the resolutions section in
languages. I think the purpose of it could probably be achieved with
just a single name/value pair.
I'd prefer to have it in a separate node, to maintain granularity.
Or even if u want to retain the resolutions, could we put it in a separate node
That sounds reasonable to me. I'd rather not cater specifically to the .NET Framework or to Java, but have a solution that tends to work well in most/all platforms and environments. This sounds like a good change. Along the same lines, I'm not opposed to your change in the error node as well. I'll make those changes (or if you'd like, you can) in the next version of the spec.
FYI - I'm currently putting together a tool that will utilize the spec for validation.