On Sun, 2008-02-03 at 22:34 -0800, Tantek =?ISO-8859-1?B?xw==?=elik
wrote:
1) it's already used to mean job title in the context of
microformats.
2) the concept that it is being proposed to represent is the *name* of
an
audio item. fn already means the name of an item. we should not
On Mon, February 4, 2008 10:30, Martin McEvoy wrote:
fn in vcard rfc 2426 inherits its semantics from X.520[2] (2001)
'commonName.' attribute
[...The Common Name attribute type specifies an identifier of an
object. A Common Name is not a directory name; it is a (possibly
ambiguous)...]
In message [EMAIL PROTECTED], Manu Sporny
[EMAIL PROTECTED] writes
We should be using TITLE for the title of audio recordings.
So, who is going to make an argument against using TITLE in hAudio?
I'm not, but I do think we should allow for distinction between the
titles of tracks, albums, works
On Sun, 2008-02-03 at 14:31 -0500, Manu Sporny wrote:
FN doesn't mean anything useful until it is wrapped by a Microformat
-
hCard, or hAudio, for example. This means that the wrapping
Microformat
brings context into the equation.
The same as if we use title outside of hcard IT doesn't mean
On 2/3/08 11:31 AM, Manu Sporny [EMAIL PROTECTED] wrote:
Martin McEvoy wrote:
I think he means Context-Aware I
And to answer Manu's no I don't think its necessary, Microformats
already ARE context aware?
Yes! This is my point exactly. If Microformats ARE context aware, then
there is the
