|
Frank writes: Why is SKiCal using different property names for the same semantics we have in iCalendar. For example, "Title" instead of "SUMMARY" or "Place-Name" instead of "LOCATION". This seems an unnecessary difference. Greg, discouraged, answers: This hurts - it makes you wonder if anyone ever reads what we write! TITLE is not SUMMARY, TITLE tags the name of an Event. P?r Lanner^ from our working group wrote about this just two weeks ago. A tittle often gives a very poor indication of what an Event is about. P?r cited some examples from New York art shows. The publishers that advise our WG have asked for a specific field for TITTLE and we have provided them with that. To reach the same precision in iCal you would need to insert a property parameter named TITLE into the SUMMARY. I have never seen anyone supporting this. Frank continues: Use of "Venue" for a category of event seems to be also an unnecessary difference. You should identify a ";LocType" parameter on "LOCATION" property, rather than diluting the semantics of "LOCATION" property. Greg surmises: Yes, I can see that. Do we have a machine understandable constrained solution for indicating the LocTypes that VENUE covers; Indoors, Outdoors, Transit, TV, Radio and Internet? I'm sorry if I have missed this. Frank again: The observations in this SKiCal presentation seem to focus on a preference for how the properties are indexed in the server, rather than functionality missing from the iCalendar format. This doesn't seem like a rationale for any changes to iCalendar. Did I miss something? Greg replies: You lost me there. The slides are extracted from a larger presentation and I chose them to show those who might have a problem visualizing the structure of RFC2445, specifically the relationships between multiple instances. Gosh, I don't know how to put it any better. As calendar objects become more complex, there is going to be ambiguity as to what property refers to what instance. One way to solve that is to keep objects monophonic and use the mechanism of related-to, as is the current thinking in iCal. We believe that we can support polyphonic calendar objects in SKiCal. Time will tell. Finally, as to why we use different property names. We create the logical model of SKiCal using graphic representation. We have discussed doing this in UML in order to remain compatible with other efforts, but we have not yet done so. This logical model must then find a home in a variety of syntaxes such as XML, RDF, LDAP and not least RFC2445. We try to utilize a neutral unique syntax in our logical models to avoid later confussion. Hence the DITS and the DOTS and so forth. When we apply this model to RFC2445 our rule is to look first to the syntax available and try to use it. When confronted with the choice of "bending" iCal or creating new tags, we tend to support the latter alternative in order to avoid ambiguity. Greg |