First Interop sponsored by C&S Consortium: July 29-30 at UCB

Schedule set:  the first Interop testing event sponsored by The Calendaring
and Scheduling Consortium will be held 29-30 July 2004 at the University of
California in Berkeley on its Berkeley Campus.  More detailed information
will be posted to the Consortium website and summarized on this list as
appropriate.

Dave Thewlis, Executive Director 
The Calendaring and Scheduling Consortium
1550 Dena Drive
McKinleyville CA 95519-4146
+1 707 840 9391 (voice)
+1 415 946 3454 (fax)
Dave.Thewlis <at> calconnect.org
www.calconnect.org

xCalendar draft revision submitted

I'd like to announce that I submitted to the Internet Drafts, on 4/14/2004, 
revision 5 of an xCalendar document.
I haven't seen it posted on the I-D index yet, though I'm sure that's 
coming. In the meantime, I can send a text or html version to anyone that asks.

I did retain all of the original authors of previous drafts as authors in 
this document, while accepting responsibility for errors. If you are a 
previous author and wish to be removed from the list of authors, please let 
me know.

This draft approaches XML calendar from a slightly different perspective 
than before. I took as a basic approach that a document could be an XML 
calendar document if it had any sort of calendaring information in XML, but 
that to be xCalendar compliant it must provide an XSLT transform that can 
create an iCalendar text file; and that any "x-" items needed to be handled 
by their own XML namespace. This fits with the strengths of XML/XSL/XSLT, 
and offers great flexibility to XML developers, while still providing 
RFC2445/6-compatible information.

Given that XML is being used extensively in applications today, I think 
it's important to have ways to work with it. There are, however, already a 
number of XML-based calendaring tools (including Semantic Web items 
developed within W3C that use RDF the Resource Description Framework); so I 
didn't see anything to be gained by trying to make the representation 
within our original drafts the "standard" for XML calendar 
representation.  I included the original xCal DTD as an example of one way 
to do things, and also included an example XSL stylesheet to transform a 
document built according to that DTD into an ".ics" file.

Re: xCalendar draft revision submitted

TimHare <at> comcast.net wrote:

> I took as a basic approach that a document could be an XML calendar 
> document if it had any sort of calendaring information in XML, but 
> that to be xCalendar compliant it must provide an XSLT transform that 
> can create an iCalendar text file;

XSLT is pretty heavyweight.  Why not just make the XML a 1-1 rendition 
of the text/calendar?

--

-- 
/==========================================\
|John Stracke      |jstracke <at> centive.com   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|Maybe only the solipsists are imaginary.  |
\==========================================/

Re: xCalendar draft revision submitted

apples and oranges

I used the drafty XML version of xCal to come up with the XSLT that 
Mozilla and others have used. I had XSLT that could translate to iCal to 
make sure I had good stuff. The XML was nice for building web pages etc.

Worked great.

Good luck Tim. A standard for calendar data expressed in XML is a good 
thing and could be used all over the place.

Gary (who has no time to follow up  )

John Stracke wrote:

> 
> TimHare <at> comcast.net wrote:
> 
>> I took as a basic approach that a document could be an XML calendar 
>> document if it had any sort of calendaring information in XML, but 
>> that to be xCalendar compliant it must provide an XSLT transform that 
>> can create an iCalendar text file;
> 
> 
> XSLT is pretty heavyweight.  Why not just make the XML a 1-1 rendition 
> of the text/calendar?
> 

Re: xCalendar draft revision submitted

Gary Frederick wrote:

>
> apples and oranges
>
> I used the drafty XML version of xCal to come up with the XSLT that 
> Mozilla and others have used. I had XSLT that could translate to iCal 
> to make sure I had good stuff. The XML was nice for building web pages 
> etc.

Enabling XSLT is a far cry from requiring it.

>
> Worked great.
>
> Good luck Tim. A standard for calendar data expressed in XML is a good 
> thing and could be used all over the place.
>
> Gary (who has no time to follow up  )
>
>
> John Stracke wrote:
>
>>
>> TimHare <at> comcast.net wrote:
>>
>>> I took as a basic approach that a document could be an XML calendar 
>>> document if it had any sort of calendaring information in XML, but 
>>> that to be xCalendar compliant it must provide an XSLT transform 

Re: xCalendar draft revision submitted

The draft doesn't preclude doing a one-to-one representation, but I also 
wanted to allow the flexibility for other smaller XML representations of 
scheduling info. Another small example in the draft shows a band's 
performance schedule; it follows its own DTD ans has its own format for 
dates, etc. - but is "compliant" because it includes a transform that can 
make that XML document into an iCalendar file. This draft allows for 
"one-way" implementations where you can go from XML to iCalendar, but not 
(easily, at least) back the other way.

I decided to require the XSL transformation because XSL was designed to 
work with XML and many programs already support it.

Tim Hare
Interested Bystander, Non-Inc.

At 12:19 PM 5/10/04, you wrote:

>TimHare <at> comcast.net wrote:
>
>>I took as a basic approach that a document could be an XML calendar 
>>document if it had any sort of calendaring information in XML, but that 
>>to be xCalendar compliant it must provide an XSLT transform that can 
>>create an iCalendar text file;
>
>XSLT is pretty heavyweight.  Why not just make the XML a 1-1 rendition of 
>the text/calendar?
>
>--
>/==========================================\

Re: xCalendar draft revision submitted

TimHare <at> comcast.net wrote:

> This draft allows for "one-way" implementations where you can go from 
> XML to iCalendar, but not (easily, at least) back the other way.

That is not acceptable.  If there is to be an XML representation of 
iCalendar, it must be a 1-1 transform, so that it can be converted in 
both directions, even by an application that doesn't know all the 
extensions used.

> I decided to require the XSL transformation because XSL was designed 
> to work with XML and many programs already support it.

That's not a reason to require it; it's a reason not to object to it.  
And, frankly, it's a false reason; it may be true that many large suites 
such as Evolution already have XSLT libraries linked in, but that's only 
a tiny fraction of the codebase that could benefit from speaking iCalendar.

>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> At 12:19 PM 5/10/04, you wrote:
>
>> TimHare <at> comcast.net wrote:
>>
>>> I took as a basic approach that a document could be an XML calendar 
>>> document if it had any sort of calendaring information in XML, but 
>>> that to be xCalendar compliant it must provide an XSLT transform 

A note regarding XSL and xCalendar

It just occurred to me that I implied that using XSLT to transform to 
iCalendar is required by my draft.

Actually, what is intended to be  required is the  inclusion of a reference 
to a stylesheet, and by implication the stylesheet itself, that can do such 
a transformation.  Nothing requires an application to use the 
transformation. Maybe the wording can be improved - but the intent is, IF 
you are going to publish your calendar information in XML, then you MUST 
provide a stylesheet so that others MAY use XSLT to transform to iCalendar 
if that is the end result that they want. It's the XML developer's 
responsibility to provide the stylesheet since they know their document and 
their DTD/Schema if used.

Tim Hare
Interested Bystander, Non-Inc.

Re: A note regarding XSL and xCalendar

TimHare <at> comcast.net wrote:

> IF you are going to publish your calendar information in XML, then you 
> MUST provide a stylesheet so that others MAY use XSLT to transform to 
> iCalendar if that is the end result that they want. It's the XML 
> developer's responsibility to provide the stylesheet since they know 
> their document and their DTD/Schema if used.

But that means it *is* required, by anybody that doesn't have a private 
arrangement to know the XML that was used.

--

-- 
/===========================================================\
|John Stracke      |jstracke <at> centive.com                    |
|Principal Engineer|http://www.centive.com                  |
|Centive           |My opinions are my own.                 |
|===========================================================|
|"I only wish I had time to get married myself, as I've told|
|m'wife many's the time."                                   |
\===========================================================/

Re: xCalendar draft revision submitted