[uf-discuss] UID in iCalendar

[Dimitri Glazkov]

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
>