[uf-discuss] Extending hCard and hCalendar vs. strict adherence to vcard and vCalendar.

Breton Slivka zen at zenpsycho.com
Fri Dec 29 08:18:50 PST 2006

There's a few rather obvious problems with this idea that I can see.  
However, before I point them out, I will note that if the benefits of  
such a plan outweigh the problems, then go for it. However I suggest  
very carefully thinking about this before going nuts with extensions.

#1. More work for implementors.  While this rarely is seen as an  
issue for people on this list, (Tantek promotes that it's far more  
important to make it easier for publishers), one has to consider that  
if you specify some extension such as date of death, how likely is it  
to be implemented by anyone other than yourself?

#2. In such an implementation, what specific benefit would having a  
specific field offer over just adding a note? Are there specific use  
cases when sorting contact information by date of death, for example,  
is important?

#3. Unreliable round tripping: This would be a fairly minor  
annoyance, but an annoyance nonetheless.

#4. Divergent standards: Are there any other extensions to icalendar  
or vcard being done by other groups and/or vendors? Is there likely  
to be in the future? This probably won't lead to as feirce a battle  
as the browser wars in the 90's, but is a potential avenue of pain  
for new application authors who are asked to implement contradictory  
features, and I think we all know how this turned out for web  
browsers in the end. Again, it's more important to make it easier for  
publishers, than for application authors, but I would ask, how easy  
has the divergent feature-sets of browsers made it for publishers?

I'm sure there's less obvious problems, and just as compelling  
arguments for extensions, but my feeling is that hCard needs to go in  
the direction of becoming more simple for publishers, more easy to  
implement, not more complex. The hCard and iCalendar standard allow  
for vendor specific extensions, anyway, if you really really need  
feature X for a specific problem. With a clever enough client, and  
publishing implementation, this can probably be done with hCard and  
hCalendar as is, while maintaining backward compatibility.

On Dec 22, 2006, at 8:55 AM, Andy Mabbett wrote:

> It has been made clear [1] that vCard and, presumably, vCalendar are
> unlikely to be developed or extended in the foreseeable future.
> It is my belief that we should not let this prevent the development of
> hCard and hCalendar; and that to do so would not harm compatibility  
> with
> the former.
> For example, we could add a "date of death" field to hCard, and simply
> mandate that it is ignored (or perhaps treated as a 'note') by parsers
> which convert hCards to vCards.
> Does anyone foresee any problems with extensions being made in this
> manner?
> [1] <http://microformats.org/wiki/vcard-suggestions#Note>
> -- 
> Andy Mabbett
>             *  Say "NO!" to compulsory ID Cards:  <http:// 
> www.no2id.net/>
>             *  Free Our Data:  <http://www.freeourdata.org.uk>
>             *  Are you using Microformats, yet: <http:// 
> microformats.org/> ?
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

More information about the microformats-discuss mailing list