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 <[EMAIL PROTECTED]> wrote:
Dimitri Glazkov wrote:
On 7/3/06, brian suda <[EMAIL PROTECTED]> wrote:
For example,
http://events.example.com/#123
would become
[EMAIL PROTECTED]
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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
