Click here to edit contents of this page.
Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available.
Append content without editing the whole page source.
Check out how this page has evolved in the past.
If you want to discuss contents of this page - this is the easiest way to do it.
View and manage file attachments for this page.
A few useful tools to manage this Site.
See pages that link to and include this page.
Change the name (also URL address, possibly the category) of the page.
View wiki source for this page without editing.
View/set parent page (used for creating breadcrumbs and structured layout).
Notify administrators if there is objectionable content in this page.
Something does not work as expected? Find out what you can do.
General Wikidot.com documentation and help section.
Wikidot.com Terms of Service - what you can, what you should not etc.
Wikidot.com Privacy Policy.
An example rule:
My thought: Should implementation (a regex) be part of a rule? I'd rather expect that the rules are purely declarative. Such named rules can then be associated with your rulesets, which I think are a great idea:
Following this example, though…
[http://feedvalidator.org/testcases]
… any such rule would be associated with a pair of ICS objects: one that's valid w/respect to the rule and one that isn't.
—jon
It was pointing to 0.1 archive, now fixed.
Thanks! Sometimes I miss the stupid little things :)
-Doug
Ben said (in email):
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)
It's a good point. I guess tests should be designed to fail at most once. OTOH a validator has to be prepared to report all failures. So maybe fail-at-most-once is a SHOULD, not a MUST, for tests?
I think each test itself should be designed to fail at most once. If the underlying library doesn't allow that (i.e. DDay.iCal would have broken immediately on empty lines, and tell nothing more about the code, until recently), then hopefully changes to the library can be made to allow for "broken" ICS files, inasmuch as it's possible. There are some cases, like improper line folding that will probably break most/all implementations, so we have to draw a line somewhere and say: "This is a serious error, and processing on the rest of the file couldn't continue."
Thanks,
-Doug
Ben,
Agreed - once we've more closely nailed down what we're looking for, I'll turn that into an XSD. :)
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'd prefer to have it in a separate node, to maintain granularity.
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.
Thanks!!
-Doug