On Dec 29, 2006, at 11:54 AM, Andy Mabbett wrote:
In message <[EMAIL PROTECTED]>,
Breton
Slivka <[EMAIL PROTECTED]> 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
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
