rdf calendar report, timezones as datatypes, test material sync

On one of my recent flights, I found some inspiration
to work on an RDF Calendar report. In particular, I wrote
up the testing framework...

  http://www.w3.org/2002/12/cal/report1173.html#testdr
  $Revision: 1.12 $ of $Date: 2005/02/26 03:30:55 $

The report was one of the things that prompted my earlier
message about timezones. While I haven't completed my investigation
of DAML Time and such, I'm sufficiently confident that
timezones should be treated as datatype properties that
I implemented the design and updated all the test materials.
I haven't written the corresponding section of the report yet.

Attached find ,fromtest-report which shows 
29 passes out of 29 for iCalendar to RDF conversion tests.

It's generated thusly:

~/w3ccvs/WWW/2002/12/cal$ make from-test >,fromtest-report 2>&1

It depends on having a bunch of swap stuff installed; I'm
not sure how much. I'd like for somebody to try to reproduce
my results.
  http://www.w3.org/2000/10/swap/

The RDF to iCalendar results aren't as good; my toIcal.py
program doesn't grok X-properties, and almost all the data
files have X- properties in them. The attached ,retest-report
shows 19 errors in 24 tests. But I'm pretty sure X- properties
are the only problem.

I'm also attaching the output of my big cvs commit command,
and my changelog just to show exactly what changed.

I'm not sure what are the corresponding changes to the schema;
I haven't made any yet.

Recalling my offer to roll back some schema changes, only
to discover I hadn't rolled them forward yet...
http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Oct/0007.html

Masahide Kanzaki encouraged me to use a new namespace URI for
this new design. I'm sympathetic to that, since I'm going
to have to go to each of my applications that use this RDF
vocabulary and update them to use timezones
as datatypes; I might as well update the namespace name while
I'm at it.

But I wonder if anybody has changed their
mind and would rather keep the old namespace.

It seems a little odd to have the test data, conversion tools, and
documentation use one schema but to leave another one lying
around, but maybe that's the right answer. I suppose if
this were a shared library I'd change the major number...

 The three principles of shared library building are:

      * Start from 1.0
        
      * If there is a change that is backwards compatible, bump minor
        number (note that ELF systems ignore the minor number)
        
      * If there is an incompatible change, bump major number
        
  --
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html


What should I call the new one? perhaps I'll change ical to cal,
to make it, for example...

 http://www.w3.org/2002/12/cal/cal#Vevent


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E