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

[Breton Slivka]

On Dec 29, 2006, at 11:54 AM, Andy Mabbett wrote:

> In message <C6922A12-48AE-4297-A28F-70759327D23C at zenpsycho.com>,  
> Breton
> Slivka <zen at zenpsycho.com> writes
>
>> 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.
>
> Who is advocating "going nuts"?

It's a rhetorical device. The intent is to warn against unrestricted  
extensions to the standard with no problem cases to back up such  
solutions. Nobody was advocating such a thing, but it is one possible  
consequence of what you suggested.

>
>> #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?
>
> You're criticising a wide concept by considering one suggested  
> example.

No, I'm using the example you suggested as an example, of the sort  
design as problem solving thought process one should be using while  
considering extensions to a format. Namely, asking the questions  
"what problem is this solving? Does it actually need to be solved?,  
How badly does it need to be solved? What are the consequences of  
solving it in this way? Are there alternative ways of solving it?"  
etc...

>
> Nonetheless, there are sufficient "dates of death" on the web to  
> suggest
> that marking them up, semantically, would be useful, and incorporating
> them in hCards, ditto.
>

useful for what? What problem would such a thing solve? I've never  
needed to find a person via their date of death, but then, I'm not a  
mortician or a police investigator, so it may very well be an actual  
problem for 80%, but this needs to be considered before creating an  
extension specifically for it, and adding complexity to an already  
somewhat difficult format. I am picking on your date of death  
example, but similar questions would need to be asked for every  
extension.

> This is especially relevant when incorporating hCards into other uFs,
> such as those for citations and reviews
>

why?

>> #3. Unreliable round tripping: This would be a fairly minor   
>> annoyance,
>> but an annoyance nonetheless.
>
> What do you mean by "Unreliable round tripping"?
>
Client X supports features A, B, C. Client Y supports features A, C,  
D.  How would you deal with exchanging data between these two  
programs, and maintaining self consistent database structures?  
Admittedly this is an issue for developers, but it becomes a problem  
for users when the author of client X and client Y don't agree on how  
to solve it.


>> #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?
>
> No, ad no. See previous discussion.
>
> [...]

Do you mind linking to any specific posts?

>
>> 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.
>
> How? Feel free to use DoD as an example.
>
> -- 
> Andy Mabbett



<div class="vcard">
<span class="fn">Abraham Lincoln</span>
<div class="org">United States</div>
<div class="adr">
   <div class="street-address">1600 Pennsylvania Ave.</div>
   <span class="locality">Washington</span>
,
   <span class="region">DC</span>
  <abbr class="dod" title="18650415">April 15, 1865</abbr>
</div>


Then, someone can correct me if this is incorrect, when a client  
written to deal with DoD encounters class="dod", it can import it  
with an "x-" prefix (for vendor specific properties, as allowed by  
vcard, I think) rather than try and do fancy things with notes. (see  
note above about client author disagreements).




-Breton