Subject: RE: XML iCal draft changes

From: "NITSCH,FRANK (HP-Germany,ex1)" <[email-masked]>
Date: Mon, 22 Oct 2001 17:54:04 +0200

Hi,

I'm happy that this community re-started its efforts in XML.
I personally believe that XML is really important enough to
deal with it in iCalendar. Hopefully there will be some good
progress in future - this would definitely help iCalendar to
find more acceptance "outside".

About "Schemas": as far as I know there's little support in
terms of tools etc. but under Windows. A standard DTD should
therefore be included in the spec; not only a Schema.
Just my 2...

Best Regards

	Frank
--
====================================================================
Frank Nitsch                           mailto:[email-masked]
--------------------------------------------------------------------
Hewlett-Packard GmbH                 | http://www.hewlett-packard.de
Mailstop ASM-NGP, Building B32/3M17  | HP-Telnet         777-2135
Herrenberger Strasse 110-140         | Phone  (+49) 07031/14-2135
D-71034 Boeblingen                   | Fax    (+49) 07031/14-8253
====================================================================
Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen
Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus,
Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms
Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081
====================================================================

> -----Original Message-----
> From: Eric R. Plamondon [mailto:[email-masked]]
> Sent: Friday, 12 October, 2001 13:39
> To: [email-masked]
> Subject: XML iCal draft changes
> 
> 
> 
> Good Morning,
> 
> The XML iCal draft has recently been resubmitted
> through the Calendaring and Scheduling Working Group.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt
> 
> This is only an initial draft to restart (re-ignite?)
> the discussion on a possible representation of iCal
> in XML. Since the older draft expired, the goal,
> with the OK from Patricia Egen and Bob Mahoney, was to
> bring the draft back into the discussion, since 
> many people have be asking about. The original authors
> will be contacted to determine whether they want to 
> continue work on the draft.
> 
> Having gone through the archives, there were a number 
> of issues with the previous drafts. This version does
> not attempt to correct them, but rather reopen the
> discussion on them.
> 
> Goal
> ----
> The goal of the XML DTD (and schema) is to represent
> ical in XML. The names, formats, and structures should
> be a direct mapping from the iCalendar RPC. It is not
> the goal to change or improve on the iCalendar RPC.
> 
> There were a few changes made to this reposting,
> from the previous draft-many-ical-xmldoc-01 document,
> outlined below.
> 
> Summary of Changes
> ------------------
> - Renamed the file from
> 	draft-many-ical-xmldoc-01
>   to
> 	draft-ietf-calsch-many-xcal-00
> - Renamed the document from
> 	"iCalendar DTD Document"
>   to
> 	"iCalendar DTD Document (xCal)"
> - removed references to "ICALXML" and replaced
> 	with "xCal"
> - changed the FPI for the DTD from 
> 	-//IETF//DTD ICALXML/iCalendar XML//EN
>   to
> 	-//IETF//DTD XCAL/iCalendar XML//EN
> - changed the FPI for standard value types from
> 	-//IETF/NOTATION ICALXML/Value Type/xxx/EN
>   to
> 	-//IETF/NOTATION XCAL/Value Type/xxx/EN
>   NOTE: these changes where made to the DTD as well.
> - changed all references from 
> 	draft-many-ical-xmldoc-01
>   to
> 	draft-many-xcal-00
> - changed the iCal namespace to xCal
> - changed the proposed MIME type from
> 	text/x-icalxml
>   to
> 	text/x-xcal
> - In some of the examples, the <![CDATA[xxx]]>
> 	xml formatting was removed (the XML version
> 	of the draft, using the DTD from rfc2629,
> 	failed to parse properly
> 
> Property Parameters
> - the following property parameters where change to
> 	reflect their iCal counterpart
> 	- delfrom  to delegated-from
> 	- delto    to delegated-to
> 	- lang     to language
> 	- trigtype to related
> 	- sentby   to sent-by
> 
> Component Properties
> - the following component properties where change to
> 	reflect their iCal counterpart
> 	- desc     to description
> 	- end      to dtend
> 	- start    to dtstart
> 	- fbdata   to freebusy
> 	- recurid  to recurrence-id
> 	- related  to related-to
> 	- last-mod to last-modified
> 	- seq      to sequence
> 	- rstatus  to request-status
> 
> Structure Properties
> - the following structure properties where change to
> 	reflect their iCal counterpart
> 	- ical     to vcalendar
> 	- event    to vevent
> 	- todo     to vtodo
> 	- journal  to vjournal
> 	- freebusy to vfreebusy
> 	- timezone to vtimezone
> 	- alarm    to valarm
> 
> Issues to be discussed
> ======================
> - should all the names be returned to upper case
> 	(or named case, as in XML schema).
> - there are a few places where attributes are used
> 	instead of child elements (e.g. in the vCalendar
> 	element the version, prodid, calscale, and method)
> - include an XML schema in this specification
> - resolve other errors in the draft document
> - correct the differences with "related" and "related-to"
> 	within the DTD
> - does the name "xCal" conflict too much with the
> 	X-Windows calendar program by the same name
> - If the original authors wish to continue work, their
> 	business information must be updated.
> - Provide a wbxml binding for xcal.
> 
> Thanks,
> Eric
> 
> -------------------------------
> Eric R. Plamondon
> Steltor - Chief Web Architect
> 2000 Peel Street, 4th Floor
> Montreal, Quebec
> mailto:[email-masked]
> http://www.steltor.com
>

---

From: "Dawson Frank (NMP/Irving)" <[email-masked]>
Date: Thu, 25 Oct 2001 14:55:26 -0500

> through the Calendaring and Scheduling Working Group.

Great.

>   NOTE: these changes where made to the DTD as well.

Suggest we remove requirement for NOTATION declarations. These don't
seem to be used very much and the support for this little used XML
feature just makes the DTD overly complex.

Also suggest getting rid of the entity declarations which were used to
allow redefintion of the DTD for the same reason; mainly simplicity.

> - changed the proposed MIME type from

As may have been mentioned, this ought to be text/xcal+xml or even
better application/xcal+xml.

> 	reflect their iCal counterpart

Why? Shorter element type names are simplier to remember and use. It
also makes the lines of xCal more likely to fit on a single line, rather
than be broken across lines. I don't support the idea of making the
names the same as in iCalendar just for "sameness" sake. 

> Issues to be discussed

No. Mixed case to ease in readability.

> 	element the version, prodid, calscale, and method)

Make the DTD simple. Avoid all attribute lists, except standard XML
attributes.

> - include an XML schema in this specification

Why? The XML schema doesn't even use the same date/time format as in
iCalendar.

> 	X-Windows calendar program by the same name

Is there a trademark issue? Otherwise, xCal or xCalendar is cool.

> 	business information must be updated.

Yes. Attribute business affilliation with Nokia and to this email
address.

> - Provide a wbxml binding for xcal.

This requires some thinking. You will want to map most commonly used
elements into the first page, next most commonly used into the next
page, etc. This will make is more terse a tokenized form.

Thanks again for kicking this back off.

-- Frank

---

From: "Dawson Frank (NMP/Irving)" <[email-masked]>
Date: Thu, 25 Oct 2001 16:31:31 -0500

John:

Helper application is a simple table translation. I think a script could
do this. Not a strong argument. 

However, having to carry unnecessary iCalendar naming conventions makes
not sense. Neither does it to leverage some simple features of XML. 

I see no logical requirement to require xCal property names to be the
same as in iCalendar. There is also no reason to do an isomeric mapping
of property and parameter right from iCalendar into xCal.

The requirement is that the mappings be semantically isomeric, as far as
possible.

-- Frank

---

From: "John Stracke" <[email-masked]>
Date: Thu, 25 Oct 2001 17:40:59 -0400

> do this. Not a strong argument. 

The point is that that table then needs to be updated over time.  We're 
better off if the script only needs to know rules, not data.

> not sense.

What harm does it do?

The primary goal here is not to create the ideal XML syntax, which accords 
with everybody's ideas of what an XML syntax should be.  That'd be nice, 
but it must be subordinate to the goal of minimizing the impedance 
mismatch between application/icalendar+xml and text/calendar.

John Stracke
Principal Engineer
Incentive Systems, Inc.
[email-masked]

---

From: "Dawson Frank (NMP/Irving)" <[email-masked]>
Date: Fri, 26 Oct 2001 07:57:46 -0500

> I believe it's important to keep the naming 
> differences between iCal and xCal to a minimum.

Have not seen any reason to make this a design requirement for the
mapping of the XML, alternative syntax (ie, xCal).

> Changing propery and parameter names between 
> iCal and xCal, from a coding perspective has 
> relatively little impact (it's just code...), 
> but will only provide a point of confusion for 
> those people trying to adopt it. The base 
> specification is the iCalendar one.

Confusion to what? Not the parser. And to the developer? As long as
there is a well defined mapping (ie, explicit table and also descriptive
prose), then there is no discernable confusion created.

> 
> As for the issue of case, I'm for mixed case,
> to ease readability. No reason, other than a 
> style preference (even though it conflicts with
> my statement about remaining consistant with 
> iCal).
> 

The "prime directive" for consistency with iCalendar is based on the
purpose for this specification. That is, it addresses a requirement for
an ALTERNATIVE, XML representation for iCalendar. It is NOT an
alternative IETF calendaring and scheduling semantic. SO, the important
design requirement is that the semantics need to remain aligned with
RFC2445. But there SHOULD BE no requirement to align the syntax, unless
there is a strong requirement that can be made for such.

This argument that we need to align case and tokens with the standard
syntax (ie, RFC2445) implies that we just don't need an XML, alternative
syntax. Yet, I think a strong argument has been made for such an
alternative syntax.

> The MIME types outlined so far are
> 	application/calendar+xml
> 	application/icalendar+xml
> 	application/xcal+xml
> 	text/xcal+xml
> I still prefer application/calendar+xml, since it
> is closer to the iCal MIME type of text/calendar. However
> any of then are acceptable. Can anyone think of 
> a reason to discount either of these?

I believe our lessons with iMIP encoding into MIME has taught us that we
should have listened to our area director's comments and gone with
"applicatin/calendar" over "text/calendar" for the MIME media  subtype
for RFC2445. Keeping that in mind, I believe that the
"application/calendar+xml" makes more sense. As it would be the XML form
of the iCalendar semantics. 

As a matter of fact, to avoid confusion with the MIME media subtype for
the revision to RFC2445, maybe we should make it's MIME media subtype
"application/calendar". Another way that we can filter iCalendar from
iCalendar v2?

> 
> With respect to the DTD / Schema issue, it really
> looks like there is interest for both.
> 

Given that the use of the market for the Schema has not panned out and
that the use of a data representation format that conflicts with primary
data type definitions that iCalendar uses (ie, date/time), I don't see
what benefit comes from integration of the schema into the DTD. As a
matter of fact, it makes the implementation of the xCal DTD that much
more complex.

-- Frank