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
On Jul 3, 2006, at 7:37 PM, Dimitri Glazkov 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
According to the RFC 4.8.4.7 Unique Identifier, the only to requirements
are:
1) Value Type: TEXT
2) Globally Unique
Any URL fits the TEXT requirement. As for globally unique, all URL only
resolve to a single location, so that makes it globally unique. The
only caveat is that if you have two
On 7/3/06, brian suda [EMAIL PROTECTED] wrote:
According to the RFC 4.8.4.7 Unique Identifier, the only to requirements
are:
1) Value Type: TEXT
2) Globally Unique
Any URL fits the TEXT requirement. As for globally unique, all URL only
resolve to a single location, so that makes it globally
I do remember awhile ago we discussed using ID as UID, i can't find the
archived message at the moment. The one concern was that UID is to be
globally unique, whereas the ID attribute is only document unique, so if
we are going to construct an implied UID, then we could look to the RFC
Tantek Çelik wrote:
Agreed with Brian's interpretation.
In addition, I think if we make a stronger suggestion (perhaps a SHOULD)
that individual hCards and hCalendar events have a unique-to-the-document
'id' attribute on their root elements, then automatic construction of
globally unique UIDs
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?
:DG
___
microformats-discuss mailing list
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
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
Dimitri Glazkov wrote:
Sorry about that! :) But.. isn't that beside the point?
Orthogonal!
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Indeed!
On 7/3/06, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote:
Dimitri Glazkov wrote:
Sorry about that! :) But.. isn't that beside the point?
Orthogonal!
:DG
___
microformats-discuss mailing list
microformats-discuss@microformats.org
I think that is up to specific implementation of a converter: I don't
believe microformat spec should go as far as to instruct whether or
how to auto-generate UID if it is missing.
Perhaps a recommendation, based on exploration of existing implementations?
:DG
On 7/3/06, Marko Mrdjenovic
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,
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
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 /
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
16 matches
Mail list logo
