Recent Forum Posts

From categories:

All categories Developers: General

Re: Single vs multiple failure

dougday 1232040410|%e %b %Y, %H:%M %Z|agohover
in discussion Hidden / Per page discussions » XML Tryout

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: Fixed link to 0.2

dougday 1232040217|%e %b %Y, %H:%M %Z|agohover
in discussion Hidden / Per page discussions » XML Tryout

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

Spec changes

dougday 1232040113|%e %b %Y, %H:%M %Z|agohover
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

Single vs multiple failure

Jon Udell 1232035046|%e %b %Y, %H:%M %Z|agohover
in discussion Hidden / Per page discussions » XML Tryout

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?

Fixed link to 0.2

Ben Fortuna 1231985656|%e %b %Y, %H:%M %Z|agohover
in discussion Hidden / Per page discussions » XML Tryout

It was pointing to 0.1 archive, now fixed.

0.1 Notes

dougday 1231883630|%e %b %Y, %H:%M %Z|agohover
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