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

[Breton Slivka]

On Jan 4, 2007, at 8:52 AM, Brian Suda wrote:

> On 1/4/07, Breton Slivka <zen at zenpsycho.com> wrote:
>> <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).
>
> --- i'll keep this breif because we are toeing that fine-line between
> discuss and dev lists. If you want to chat more about this, we can
> take this to the dev list.
>
> The problem with random x- prefixes is that a parse can NOT determine
> if the value 'dod' is meant to convey semantics (date of death) or
> that is purely a CSS style.
>
> For instance:
> <div class="vcard">
> <span class="fn president blue-box call-out alert">Abraham Lincoln</ 
> span>
> </div>
>
> what becomes 'x-???' in vcard and what doesn't?
>
> BEGIN:VCARD
> FN:Abraham Lincoln
> X-PRESIDENT:Abraham Lincoln
> X-BLUE-BOX:Abraham Lincoln
> X-CALL-OUT:Abraham Lincoln
> X-ALERT:Abraham Lincoln
> END:VCARD
>
> Because of this, there has not been any attempt to add in the 'X-'
> parameters into the parsing rules.
>
> If you (or anyone) is still interested, feel free to email the dev- 
> list.
>
> Thanks,
> -brian


Since I don't have access to the dev list, and only have a passing  
interest in this, I will simply quickly clarify the point I was  
attempting to make in the first post.

x- extensions being vendor specific, the decision of which classes  
become x-___ would be vendor specific, and only if a specific  
application really *really* needs it. Since such extensions are  
unlikely to become globally adapted, the problem of global  
application doesn't come into it. 1 website, 1 vendor, 1  
application.  The problem of adapting extensions to the format as a  
standard is too big to take so lightly though, so I wouldn't  
reccomend it beyond specific non standard applications. Applications  
still need to work together for the most part, and allowing this just  
opens a big complicated can of worms.