adr-poll: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(General comments)
 
(7 intermediate revisions by 3 users not shown)
Line 15: Line 15:


===Object===
===Object===
(please give reasons)
* [[User:Brian|Brian Suda]]
* [[User:ScottReynen|Scott Reynen]]


==Wording==
==Wording==
Line 38: Line 39:


==General comments==
==General comments==
ADR is for structured information, if you do NOT have structured information then use the LABEL property. There is NO REASON to make any specical conditions for the ADR element. The spec and RFC are clear enough on these topics
:<code>Label</code> is not a sub-property of <code>adr</code>; it is therefore not suitable for addresses with no <code>fn</code>. Th reasons for this proposal are as outlined on the issues page cited. [[User:AndyMabbett|Andy Mabbett]] 14:13, 10 Apr 2007 (PDT)
::this makes no sense? ofcourse LABEL is not a sub-property of ADR, it is ANOTHER property entirerly designed SPECIFICALLY for address information with no structure! The use of LABEL has been added to the issues-page already and attiquitely addresses this issue - if your CMS can NOT add the fine grained support for different ADR sub-properties then it should be class="label" instead of class="adr". As for FN i don't understand what you are attempted to describe. ADR and FN are seperate. An ADR does NOT need an FN and an FN does NOT need an ADR? neither are sub-properties of each other? therefore it is completely acceptable to have an FN and a LABEL and an ADR and/or any combination of them. [[User:Brian|Brian Suda]] 21:18, 10 Apr 2007 (GMT)
:::<code>Label</code> is a sub-property of <code>hCard</code>, which requires an <code>fn</code>. <code>Adr</code> is a stand-alone uF. <code>Label</code> is not.[[User:AndyMabbett|Andy Mabbett]] 14:25, 10 Apr 2007 (PDT)
None of the proposed output fields seem suitable for unstructured address information. They all have specific meanings that we couldn't maintain by putting arbitrary address information into them. Also, why not just use ad-hoc semantic HTML, e.g. class="address", for this? I don't see any benefit to using ADR for something incompatible with existing ADR tools. [[User:ScottReynen|Scott Reynen]]
Or if you have the ability to change &lt;div&gt;$ADR_Var_here&lt;/div&gt; to &lt;div class="adr"&gt;$ADR_Var_here&lt;/div&gt; in  your CMS templates, then you can probably also do &lt;div class="adr"&gt;&lt;div class="extended-address"&gt;$ADR_Var_here&lt;/div&gt;&lt;/div&gt; I see no need to make any special cases. The minute we begin to try to make semantics smarter than they really are we will get burnt - there has been three suggestion about how to handle this, either class="label", add the additional one sub-property as needed and overload that with all the values, or just use a regular semantic value that is NOT a microformat. I generally agree with Scott, ADR is optional, if you can't use it as the spec describes, then don't use it. Use and equivalently semantic value such as LABEL or ADDRESS. A class="label" outside of a class="vcard" is not against any HTML rules and will just be ignored by any hCard parsers. [[User:Brian|Brian Suda]] 09:53, 11 Apr 2007 (UTC)

Latest revision as of 09:56, 11 April 2007

Change to adr spec

Further to discussion at hcard-brainstorming#ADR with no children, it is proposed to amend the adr spec, and the corresponding part of the hCard spec, thus:

Where the adr has content, but no valid sub-properties, parsers [MAY | SHOULD | MUST] output the content of that adr as a single vCard [output-field] field.

Please indicate you support or objections preferred wording and choice of output-field, below, using an asterisk and three tildes (* ~~~), followed by any comments. Please indicate your preferences, even if you object to the main proposal, so that they may still be considered if the proposal carries. You may change your votes at any time, until a community decision is made.

Main proposal

Support

Object

Wording

MAY

SHOULD

MUST

Output field

street-address

extended-address

region

locality

General comments

ADR is for structured information, if you do NOT have structured information then use the LABEL property. There is NO REASON to make any specical conditions for the ADR element. The spec and RFC are clear enough on these topics

Label is not a sub-property of adr; it is therefore not suitable for addresses with no fn. Th reasons for this proposal are as outlined on the issues page cited. Andy Mabbett 14:13, 10 Apr 2007 (PDT)
this makes no sense? ofcourse LABEL is not a sub-property of ADR, it is ANOTHER property entirerly designed SPECIFICALLY for address information with no structure! The use of LABEL has been added to the issues-page already and attiquitely addresses this issue - if your CMS can NOT add the fine grained support for different ADR sub-properties then it should be class="label" instead of class="adr". As for FN i don't understand what you are attempted to describe. ADR and FN are seperate. An ADR does NOT need an FN and an FN does NOT need an ADR? neither are sub-properties of each other? therefore it is completely acceptable to have an FN and a LABEL and an ADR and/or any combination of them. Brian Suda 21:18, 10 Apr 2007 (GMT)
Label is a sub-property of hCard, which requires an fn. Adr is a stand-alone uF. Label is not.Andy Mabbett 14:25, 10 Apr 2007 (PDT)

None of the proposed output fields seem suitable for unstructured address information. They all have specific meanings that we couldn't maintain by putting arbitrary address information into them. Also, why not just use ad-hoc semantic HTML, e.g. class="address", for this? I don't see any benefit to using ADR for something incompatible with existing ADR tools. Scott Reynen

Or if you have the ability to change <div>$ADR_Var_here</div> to <div class="adr">$ADR_Var_here</div> in your CMS templates, then you can probably also do <div class="adr"><div class="extended-address">$ADR_Var_here</div></div> I see no need to make any special cases. The minute we begin to try to make semantics smarter than they really are we will get burnt - there has been three suggestion about how to handle this, either class="label", add the additional one sub-property as needed and overload that with all the values, or just use a regular semantic value that is NOT a microformat. I generally agree with Scott, ADR is optional, if you can't use it as the spec describes, then don't use it. Use and equivalently semantic value such as LABEL or ADDRESS. A class="label" outside of a class="vcard" is not against any HTML rules and will just be ignored by any hCard parsers. Brian Suda 09:53, 11 Apr 2007 (UTC)