[uf-discuss] UID in iCalendar

[brian suda]

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
>