Subject: [Ietf-calsify] another thought for simplification / levels

From: TimHare at comcast.net ([email-masked])
Date: Mon Dec 20 18:12:47 2004

This idea was inspired by someone who asked about my XML-with-calendar guideline draft; I'm posting it here because I think this may be the most appropriate place to begin this discussion.

We've had some discussion about having various levels of iCalendar to allow simplification. This would of course require a mechanism that allowed one to know what levels were supported by sender and receiver. There are also quite a few people that are thinking about and working on events/scheduling information in XML - which makes sense because of the large number of XML tools available to developers and its growing use as an interchange mechanism. This has prompted me to think that perhaps the "simplified" version of iCalendar ought to be an XML version instead? 

There are several advantages to this idea in my opinion:

	1. We could use XML to group things from different levels together (this is just an example)
	    <vcalendar>
	      <vevent>
	        <basic-event-info>
	          (whatever we decide level 0 stuff is goes here)
	         </basic-event-info>
	         <extended-stuff>
	           (more advanced items go here)
	         </extended-stuff>
	      </vevent>
	    </vcalendar>

	2. XML allows developers to use namespaces for extensions and additions
	3. XML tools are prevalent in many development packages and databases systems, easing development
	4. XML is understood at some level by many more developers 
	5. We can always "down-convert" an XML representation to iCalendar through XSLT
	6. For events calendars and the like: the structure of XML would make it easier to create search tools for events

There of course will be negatives - one of which is the addition of code to existing products that support iCalendar, to also support the new XML-based format. My instincts tell me that many of these products already support XML  in some ways, so  that much of the software infrastructure to support XML is already there (for example, MS Office supports XML for quite a few things now); but I am not a software vendor, so take that with a grain of salt unless vendor representatives on this list would care to comment.

I posting this a discussion-generator. This being the holidays,  I don't expect a lot of discussion right at the moment, but please, let's kick this one around for a bit.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Dec 20 19:13:02 2004

>	           (more advanced items go here)

If (an example) if RRULE were in an extended set, what would be the 
advantage
of wrapping it with another tag?   Other than making it visually 
separate, what would
be the advantage?

In 2445 when you do not know a component, property, or parameter name, you
are suppose to ignore it anyway.

And it is more complicated than that. Some properties may be in one RFC
an not another or some extended properties may exist in newer RFC's causing
yet more extensions.

The extensions method must be a non-linier solution that can include
or exclude future RFCs. Just adding the <extended-stuff> wrapper
will cause only a delay and not a solution to the problem.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041220/3d8aab70/smime.bin

---

From: TimHare at comcast.net ([email-masked])
Date: Tue Dec 21 15:36:06 2004

Just to clear something up - my XML was just an example, not the definitive 
way to do it; obviously it would take a lot of thought to get the XML right.

And in answer to other posts -  I think I agree that XML-calendar is 
another project, different from calendar simplification; however if 
simplification doesn't happen in a relatively short time frame, those who 
are working on calendaring in other venues (RDF Calendar being just one 
example) may produce something that works, in XML,  before simplification 
and interoperability are complete for our set of RFCs. And in my 
not-so-humble opinion of the industry as a whole,  working stuff trumps 
IETF standards - even if the working protocols later get written up as 
standards.  I haven't seen a lot of work on the 
simplification/interoperability front lately on this list (it may be 
happening elsewhere, though).

At 10:12 PM 12/20/04, Doug Royer wrote:

>If (an example) if RRULE were in an extended set, what would be the advantage
>of wrapping it with another tag?   Other than making it visually separate, 
>what would
>be the advantage?
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare

---

From: pregen at egenconsulting.com ([email-masked])
Date: Wed Dec 29 07:51:09 2004

Hi Tim.  Sorry for the delay in posting to the list.  I'm weeding through 
my emails - message here is don't go away for the holidays - it kills you 
later - 8-( 

I agree with you that other projects are in the works and probably already 
have come up with implementations that don't follow the standards. Indeed, 
working code will always override standards, unfortunately (or fortunately 
- depending on your point of view.) 

I am still, as I have always been, an end user (not a calendar developer) 
who has been waiting, since 1989, for good calendar interoperability and a 
way to search peoples schedules - anywhere.  And when I talk to other 
users/companies, that's all they want as well (for now).

I am working with a client right now who is a large organization and who 
runs three - count them three - different calendaring systems.  This is 
because of recent mergers.  It's not what they want but moving large 
amounts of people to one calendar is not feasible, economically,  in the 
near future.  So, they are back to using the phone to set up meetings 
among the three groups.  To them, they have gone backwards in time.

Yes, with the extended reach of the internet, we can start looking at 
exciting ways to do calendar searches, etc.  However, right now, several 
organizations would simply be happy with "my calendar product talks to 
your calendar product."  Easily.  Without magic mirrors and addon 
products.  Whatever we do to get there - standards or not - will work in 
our books. 

[email-masked] 
Sent by: [email-masked]
12/21/2004 05:41 PM

To
[email-masked]
cc
[email-masked]
Subject
Re: [Ietf-calsify] another thought for simplification / levels

Just to clear something up - my XML was just an example, not the 
definitive 
way to do it; obviously it would take a lot of thought to get the XML 
right.

advantage
>of wrapping it with another tag?   Other than making it visually 
separate, 

Tim Hare