Change to adr spec
adrhas content, but no valid sub-properties, parsers [MAY | SHOULD | MUST] output the content of that
adras 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.
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
Labelis 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)