Subject: xCalendar draft revision submitted

From: [email-masked]
Date: Mon, 10 May 2004 12:03:28 -0400

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.

I'm sure there are errors and revisions to be made to this draft.. please, 
however, note them on the list, so that all may contribute if they wish.

Thanks
Tim Hare
Interested Bystander, Non-Inc.

---

From: John Stracke <[email-masked]>
Date: Mon, 10 May 2004 12:19:29 -0400

[email-masked] 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      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|Maybe only the solipsists are imaginary.  |
\==========================================/

---

From: Gary Frederick <[email-masked]>
Date: Mon, 10 May 2004 11:55:44 -0500

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 :-( )

---

From: John Stracke <[email-masked]>
Date: Mon, 10 May 2004 13:11:38 -0400

Gary Frederick wrote:

> 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.

>>> 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      [email-masked]              |
|Principal Engineer|http://www.centive.com            |
|Centive           |My opinions are my own.           |
|=====================================================|
|Organ transplants are best left to the professionals.|
\=====================================================/

---

From: [email-masked]
Date: Mon, 10 May 2004 13:30:04 -0400

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

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

>>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?
>
>--

---

From: John Stracke <[email-masked]>
Date: Mon, 10 May 2004 13:45:31 -0400

[email-masked] 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.

-- 
/==============================================================\
|John Stracke      [email-masked]                       |
|Principal Engineer|http://www.centive.com                     |
|Centive           |My opinions are my own.                    |
|==============================================================|
|"Where's your sense of adventure?" "In front of a roaring fire|
|with a cup of cocoa."                                         |
\==============================================================/

---

From: [email-masked]
Date: Mon, 10 May 2004 14:23:16 -0400

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

---

From: John Stracke <[email-masked]>
Date: Mon, 10 May 2004 14:36:35 -0400

[email-masked] 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      [email-masked]                    |
|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."                                   |
\===========================================================/

---

From: [email-masked]
Date: Mon, 10 May 2004 20:42:12 -0400

Thanks for doing this draft Tim.  Bob and I will check to see where the 
draft is in the "queue."
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

---

From: Libby Miller <[email-masked]>
Date: Tue, 11 May 2004 08:30:24 +0100 (BST)

That's a very interesting approach Tim. Have you seen the GRDDL work?

http://www.w3.org/2004/01/rdxh/spec

Libby

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 13 May 2004 12:14:09 -0700 (PDT)

There has been some discussion among the chairs and the authors of the
various xCalendar (ie, XML for iCalendar) drafts about how to handle this
document (or documents).  Here is our proposed path forward on this.
Please comment if you have objections or suggestions for handling this
differently.

There has apparently never been an "XML version of iCalendar" work item in
the charter for this Working Group.  Nor did the proposed revised charter
that I posted in February (about which more later) include this item.

Rather than adding it to the charter now, we suggest that this work can
proceed as individual submissions to the IETF.  Internet-Draft documents
on this topic would be named draft-<author>-xcalendar-NN or similar.
They can and should be discussed on this list (at least until the point
where high volume would cause us to say the discussion should be taken
elsewhere).  The authors can ask for informal last call on this list if
they desire, and can submit the documents to the IESG for publishing as
RFCs (it is entirely reasonable for documents handled in this fashion to
become Standards Track RFCs).  But the documents would not be tracked as
WG work items, nor would the eventual closing of this WG depend on their
being finished.

So I believe we can expect new individual submissions on xCalendar to
appear soon.  There won't be a new draft-ietf-calsch-xcal-NN document.

 - RL "Bob"