Re: [uf-discuss] hCard names - n vs. fn
In message [EMAIL PROTECTED], Ciaran McNulty [EMAIL PROTECTED] writes On a side-note, the issue of what to do with user-entered names where one isn't sure of the formatting is one I've also had issues with and could do with some attention - for now hCard is only going to be useful in applications where the author has the users' names split into the relevant fields and for me it's a major stumbling block. In the case I cited, there are three template fields: honorific-prefix name honorific suffix given that, in any individual case, the makeup of the name field is unknown, and could be: FirstName Surname FirstName Nickname Surname FirstName MiddleName Surname FirstName Surname Surname FirstName MiddleName Surname Surname EasternFamilyName EasternGivenName or even: OneWordName how would people suggest applying name-related hCard properties? -- 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 microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
Drew McLellan wrote: It's the fn=n optimisation ... from my notes it seems that it was created around the same time as a.include. So if the fn=n optimisation is being used, does that existing spec deny the ability to include other n properties? And if not, what wqould the code look like? -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On 4/22/07, Andy Mabbett [EMAIL PROTECTED] wrote:
I'm not clear on the relationship between n and fn in hCard. I have
some markup:
TD class=n
SPAN class=honorific-prefixThe Rt Hon/SPANnbsp;
nbsp;
SPAN class=fnTony Blair/SPAN
nbsp;
SPAN class=honorific-suffixMP/SPAN
/TD
Operator gives:
fn=Tony Blair
object n {
object honorific-prefix {
0=The Rt Hon
}
object honorific-suffix {
0=MP
}
Which is right, and is the mark-up valid?
Operator is correct in this instance. The markup is valid in the
sense there's nothing wrong according to the spec, but it's probably
not conveying the meaning you hope.
'fn' in your example is clearly Tony Blair
A parser will find the 'n' and then find its sub properties
'honorific-prefix' and 'honorific-suffix' but not find any other
sub-properties such as 'given-name' because they are not present.
What may be causing confusion on this issue are the implied-n
optimisation rules [1]. It's important to note that they only come
into effect when n is not present.
On a side-note, the issue of what to do with user-entered names where
one isn't sure of the formatting is one I've also had issues with and
could do with some attention - for now hCard is only going to be
useful in applications where the author has the users' names split
into the relevant fields and for me it's a major stumbling block.
At the moment, by omitting n, the author is making an assertion about
the formatting of the fn, i.e. the author is effectively saying 'I do
not need to specify n subproperties because fn is in one of the
standard formats'.
It's not correct behaviour to wrap arbitrary user-entered names in fn
and assume that parsers will work it all out.
One possible solution, which I've experimented with, is to use:
span class=fn n
span class=nickname$user_entered_name/span
/span
Then whatever the user has entered as their login becomes their full
name and nickname, and the other vCard fields are effectively blank.
Actually span class=fn$foo/span where $foo is one word already
has this optimisation [2]
-Ciaran McNulty
[1] http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization
[2] http://microformats.org/wiki/hcard#Implied_.22nickname.22_Optimization
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On 24 Apr 2007, at 22:50, Ryan King wrote: On Apr 24, 2007, at 2:25 PM, Drew McLellan wrote: They're also subprops of fn when n isn't present. But n is present. They are? If so, that's news to me. Maybe you're referring to the implied-n rules? It's the fn=n optimisation ... from my notes it seems that it was created around the same time as a.include. drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On Apr 24, 2007, at 2:25 PM, Drew McLellan wrote: They're also subprops of fn when n isn't present. But n is present. They are? If so, that's news to me. Maybe you're referring to the implied-n rules? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On 4/23/07, Paul Wilkins [EMAIL PROTECTED] wrote: For the purposes of discussion, a more generic version of this is div class=vcard span class=n span class=honorific-prefixThe Rt Hon/span span class=fnTony Blair/span span class=honorific-suffixMP/span /span /div An update may be required, where then fn is looked for first, and parsed out into appropriate n fields, then after that the n fields are updated from the remaining information. --- well, this a tricky situation because the author has been MORE explicit with the use of the N property. We can happily pick apart things from FN when N is not present, but when the author expresses deeper semantics IMHO i don't think we should be implying any additional information, unless there is a very good reason. In this situation there are two possibilities. 1) drop the N all together - you lose the extracting of the prefixes and suffixes, but get the FN-N correct 2) add an additional class of 'family-name' to the class=fn - this will incorrectly put the WHOLE FN value in the N's family name field as with everything, there are trade-offs. Microformats are only ment to cover the 80% not 100% of extreme edge cases. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
In message
[EMAIL PROTECTED], Brian
Suda [EMAIL PROTECTED] writes
On 4/23/07, Paul Wilkins [EMAIL PROTECTED] wrote:
For the purposes of discussion, a more generic version of this is
div class=vcard
span class=n
span class=honorific-prefixThe Rt Hon/span
span class=fnTony Blair/span
span class=honorific-suffixMP/span
/span
/div
An update may be required, where then fn is looked for first, and parsed out
into appropriate n fields, then after that the n fields are updated from the
remaining information.
--- well, this a tricky situation because the author has been MORE
explicit with the use of the N property. We can happily pick apart
things from FN when N is not present, but when the author expresses
deeper semantics IMHO i don't think we should be implying any
additional information, unless there is a very good reason.
Since you're answering a copy of my post, and not the original, I'll
remind you that I went on to say:
Tails gives:
Name: The Rt Hon Tony Blair MP
Full Name: Tony Blair
Given Name: %
Family Name: %
Additional Name: %
Honorific Prefix: The Rt Hon
Honorific Suffix: MP
Nickname: %
Operator gives:
fn=Tony Blair
object n {
object honorific-prefix {
0=The Rt Hon
}
object honorific-suffix {
0=MP
}
and exports:
BEGIN:VCARD
N;CHARSET=UTF-8:;;;The Rt Hon;MP
FN;CHARSET=UTF-8:Tony Blair
Which is right, and is the mark-up valid? It's not possible to mark up
given- and family- names, as this is template generated, and the
granularity cannot be guaranteed.
In this situation there are two possibilities.
1) drop the N all together
- you lose the extracting of the prefixes and suffixes, but get the
FN-N correct
2) add an additional class of 'family-name' to the class=fn
- this will incorrectly put the WHOLE FN value in the N's family name field
1) Seems harmful, as data is lost.
2) is, as you say incorrect; but also impossible in the case concerned.
--
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
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes TD class=n SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=fnTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD On reflection, would it make more sense to reverse the n and fn, thus: TD class=fn SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=nTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD ? -- 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 microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On Apr 23, 2007, at 2:16 PM, Andy Mabbett wrote:
Tails gives:
Name: The Rt Hon Tony Blair MP
Full Name: Tony Blair
Given Name: %
Family Name: %
Additional Name: %
Honorific Prefix: The Rt Hon
Honorific Suffix: MP
Nickname: %
Operator gives:
fn=Tony Blair
object n {
object honorific-prefix {
0=The Rt Hon
}
object honorific-suffix {
0=MP
}
and exports:
BEGIN:VCARD
N;CHARSET=UTF-8:;;;The Rt Hon;MP
FN;CHARSET=UTF-8:Tony Blair
Which is right, and is the mark-up valid?
Operator is right, and the markup is valid.
Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
From: Andy Mabbett [EMAIL PROTECTED] On reflection, would it make more sense to reverse the n and fn, thus: TD class=fn SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=nTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD ? No, for then - fn is The Rt Hon Tony Blair MP - n is Tony Blair Neither of which are acceptable. The former code is: TD class=n SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=fnTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD which gives - fn Tony Blair - n honorific-prefix The Rt Hon - n honorific-suffix MP The rest of the name can be implied by quoteallowing the FN property to imply N property values in typical cases/quote My question to Brain is, even though we're being more explicit with the use of the N property, should that permit us to then totally disregard any FN information? Who's responsibility is it to parse the information in FN. given-name (space) family-name family-name (comma) given-name family-name (comma) given-name-first-initial family-name (space) given-name-first-initial (optional period) Is this to rest on the shoulders of people creating templates for their pages, or can it be done consistantly and reliably by the tools that interpret them. -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On Apr 23, 2007, at 12:55 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes TD class=n SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=fnTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD On reflection, would it make more sense to reverse the n and fn, thus: TD class=fn SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=nTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD honorific-prefix and honorific-suffix are subproperties of n, so no, I don't think it makes more sense. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCard names - n vs. fn
I'm not clear on the relationship between n and fn in hCard. I have
some markup:
TD class=n
SPAN class=honorific-prefixThe Rt Hon/SPANnbsp;
nbsp;
SPAN class=fnTony Blair/SPAN
nbsp;
SPAN class=honorific-suffixMP/SPAN
/TD
Tails gives:
Name: The Rt Hon Tony Blair MP
Full Name: Tony Blair
Given Name: %
Family Name: %
Additional Name: %
Honorific Prefix: The Rt Hon
Honorific Suffix: MP
Nickname: %
Operator gives:
fn=Tony Blair
object n {
object honorific-prefix {
0=The Rt Hon
}
object honorific-suffix {
0=MP
}
and exports:
BEGIN:VCARD
N;CHARSET=UTF-8:;;;The Rt Hon;MP
FN;CHARSET=UTF-8:Tony Blair
Which is right, and is the mark-up valid? It's not possible to mark up
given- and family- names, as this is template generated, and the
granularity cannot be guaranteed.
--
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
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
For the purposes of discussion, a more generic version of this is div class=vcard span class=n span class=honorific-prefixThe Rt Hon/span span class=fnTony Blair/span span class=honorific-suffixMP/span /span /div An update may be required, where then fn is looked for first, and parsed out into appropriate n fields, then after that the n fields are updated from the remaining information. -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
