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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
