[uf-discuss] UID in iCalendar

[Dimitri Glazkov]

I've looked at this again and here's a couple of things I don't like
in this algorithm:

* Throwing away the data in the last step. I am very unhappy about
ignoring good event information, even though it does not contain
explicit UIDs.

* No reliance on URL property of vevent. IMHO, vevent is used with a
URL -- the link to the actual event page. Maybe that could be another
implicit UID?

What are your thoughts on this, folks?

:DG<

On 7/3/06, Dimitri Glazkov <dimitri.glazkov at gmail.com> wrote:
> If I read the spec correctly, yes, UID is required for the VEVENT
> component, which means that UID is required for hCalendar.
>
> Okkayy... So, here's another stab at the implied algorithm:
>
> * if UID is specified, use it
> * otherwise, if id attribute is specified, construct full URL with
> fragment identifier and use it as UID
> * otherwise, if only one vevent present in document, use document URL
> as UID
> * otherwise, only accept the first vevent with document URL as UID and
> discard all others?
>
> :DG<
>
> On 7/3/06, brian suda <brian.suda at gmail.com> wrote:
> > I stand corrected.
> >
> > In section 4.6.1 Event Component, of the RFC it lists which properties
> > are optional, and UID is in that list. That is what i cited in the last
> > email.
> >                 ; the following are optional,
> >                 ; but MUST NOT occur more than once
> >
> >                 class / created / description / dtstart / geo /
> >                 last-mod / location / organizer / priority /
> >                 dtstamp / seq / status / summary / transp /
> >                 uid / url / recurid /
> >
> > Although it doesn't list which items are required. It does seem a bit
> > silly to have an event without a dtstart. So i guess there needs to be
> > some interpretation about the intention of the spec. Since the portion
> > of the spec where REQUIRED is found is closer to the actual definition
> > of UID, i would assume the authors intended that UID be required.
> >
> > Anyone disagree?
> >
> > This could then change the steps of how to build an implied-UID.
> >
> > -brian
> >
> > Marko Mrdjenovic wrote:
> > > Brian,
> > >
> > > I said that one needs to be specified if it's required. The RFC says
> > > this in section "4.8.4.7 Unique Identifier":
> > >
> > >   Conformance: The property MUST be specified in the "VEVENT", "VTODO",
> > >   "VJOURNAL" or "VFREEBUSY" calendar components.
> > >
> > > I think the important thing is to make hCalendar as importable but to
> > > keep it as human friendly as possible. The spec should not require a
> > > UID but if it's required it should be recommended to the converter how
> > > to create one.
> > >
> > > Regards,
> > > Marko Mrdjenovic
> > >
> > > brian suda wrote:
> > >
> > >> I like these steps and i'm pretty indifferent on HOW the implied-UID
> > >> value is formed, i just wanted to point out that fragment identifiers
> > >> are not globally unique, we'd need to add more to it, where/what gets
> > >> added isn't important. Either behind an '@' like the recommendation, or
> > >> the plain URL, it doesn't really matter to me.
> > >>
> > >> Marko Mrdjenovic suggested that we should always create a UID, the RFC
> > >> says that UID is optional so i'm not sure we should force one to exists.
> > >>
> > >>                ; the following are optional,
> > >>                ; but MUST NOT occur more than once
> > >>
> > >>                class / created / description / dtstart / geo /
> > >>                last-mod / location / organizer / priority /
> > >>                dtstamp / seq / status / summary / transp /
> > >>                uid / url / recurid /
> > >>
> > >> -brian
> > >>
> > >>
> > >> Dimitri Glazkov wrote:
> > >>
> > >>
> > >>> Sorry about that! :) But.. isn't that beside the point?
> > >>>
> > >>> The implied UID algorithm could be as follows:
> > >>>
> > >>> * if UID is specified, use it
> > >>> * otherwise, if id attribute is specified, construct full URL with
> > >>> fragment identifier and use it as UID
> > >>> * otherwise, if only one vevent present in document, use document URL
> > >>> and use it as UID
> > >>> * otherwise, don't specify UID.
> > >>>
> > >>> :DG<
> > >>>
> > >>> On 7/3/06, David Janes -- BlogMatrix <davidjanes at blogmatrix.com> wrote:
> > >>>
> > >>>> Dimitri Glazkov wrote:
> > >>>>
> > >>>>> On 7/3/06, brian suda <brian.suda at gmail.com> wrote:
> > >>>>>
> > >>>>>> For example,
> > >>>>>> http://events.example.com/#123
> > >>>>>> would become
> > >>>>>> 123 at events.example.com
> > >>>>>>
> > >>>>> Why not just keep it as is, http://events.example.com/#123?
> > >>>>>
> > >>>> You can't have "id" attributes that start with a number [1], so you
> > >>>> would have to create invalid XHTML to imply the URI.
> > >>>>
> > >>>> Regards, etc...
> > >>>> David
> > >>>>
> > >>>> [1] http://www.w3.org/TR/REC-html40/types.html#type-id
> > >>>>
> > >>> _______________________________________________
> > >>> microformats-discuss mailing list
> > >>> microformats-discuss at microformats.org
> > >>> http://microformats.org/mailman/listinfo/microformats-discuss
> > >>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> microformats-discuss mailing list
> > >> microformats-discuss at microformats.org
> > >> http://microformats.org/mailman/listinfo/microformats-discuss
> > >>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > microformats-discuss mailing list
> > > microformats-discuss at microformats.org
> > > http://microformats.org/mailman/listinfo/microformats-discuss
> > >
> >
> > _______________________________________________
> > microformats-discuss mailing list
> > microformats-discuss at microformats.org
> > http://microformats.org/mailman/listinfo/microformats-discuss
> >
>