[uf-discuss] UID in iCalendar

brian suda brian.suda at gmail.com
Mon Jul 3 13:49:32 PDT 2006


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
>



More information about the microformats-discuss mailing list