Recent Forum Posts
From categories:

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

Re: Single vs multiple failure by dougdaydougday, 15 Jan 2009 17:26

Thanks! Sometimes I miss the stupid little things :)
-Doug

Re: Fixed link to 0.2 by dougdaydougday, 15 Jan 2009 17:23
Spec changes
dougdaydougday 15 Jan 2009 17:21
in discussion Hidden / Per page discussions » XML Tryout

Ben,

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.

Thanks!!
-Doug

Spec changes by dougdaydougday, 15 Jan 2009 17:21

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?

Single vs multiple failure by Jon UdellJon Udell, 15 Jan 2009 15:57

It was pointing to 0.1 archive, now fixed.

Fixed link to 0.2 by Ben FortunaBen Fortuna, 15 Jan 2009 02:14
0.1 Notes
dougdaydougday 13 Jan 2009 21:53
in discussion Hidden / Per page discussions » XML Tryout

An example rule:

<compositionRule type="exclusion" pattern="((\r(?=[^\n]))|((?<=[^\r])\n))" fail="crlfPairError" isWarning="true" />

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:

<ruleset name="Strict2_0" description="iCalendar 2.0 Strict">
  <add name="emptyLine" /> 
  <add name="reqVersion" /> 
  <add name="reqProdID" /> 
  </ruleset>
  <ruleset name="Loose2_0" description="iCalendar 2.0 Loose" /> 
  <ruleset name="StrictMIME2_0" description="iCalendar 2.0 Strict with MIME attachments" /> 
</rulesets>

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

0.1 Notes by dougdaydougday, 13 Jan 2009 21:53
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License