XML Tryout

Format Considerations

I've attempted to put together a tentative set of XML documents that follow an imaginary spec (what we're trying to create - the spec). Would you please take a look at them and see what you think?

icalvalidSchema V0.2

Older versions

icalvalidSchema V0.1

—Doug

0.1 Notes

dougday 13 Jan 2009 21:53

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

Last edited on 13 Jan 2009 21:54 by dougday Show more

Fixed link to 0.2

Ben Fortuna 15 Jan 2009 02:14

It was pointing to 0.1 archive, now fixed.

Re: Fixed link to 0.2

dougday 15 Jan 2009 17:23

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

Single vs multiple failure

Jon Udell 15 Jan 2009 15:57

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?

Last edited on 15 Jan 2009 16:01 by Jon Udell Show more

Re: Single vs multiple failure

dougday 15 Jan 2009 17:26

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

Spec changes

dougday 15 Jan 2009 17:21

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