Template talk:Infobox settlement/Archive 10

Broken microformat

{{editprotected}}

Will somebody please reverse this edit which broke the hCard microformat. Thank you. Andy Mabbett | Talk to Andy Mabbett 22:39, 21 August 2008 (UTC)[reply]

What exactly is broken in the microformat? --Qyd (talk) 03:44, 22 August 2008 (UTC)[reply]

It includes three, separate addresses for the settlement, one of which is just a postcode. Andy Mabbett | Talk to Andy Mabbett 08:16, 22 August 2008 (UTC)[reply]

Done Happy‑melon 14:36, 23 August 2008 (UTC)[reply]

Thank you. Andy Mabbett | Talk to Andy Mabbett 14:40, 23 August 2008 (UTC)[reply]

It includes three separate address elements. Why would that be wrong? Firefox operator extension is able to put the pieces together into one address entity (such as a ms outlook contact). --Qyd (talk) 14:55, 23 August 2008 (UTC)[reply]

It includes three separate address. ADR is defned as a plural property in hCard and vCard. Settlements have one address, not three. Andy Mabbett | Talk to Andy Mabbett 15:06, 23 August 2008 (UTC)[reply]

I'm afraid you interpreted the specifications wrongly. adr is "OPTIONAL, and MAY occur more than once". Attributes included in adr can be declared in different places inside the vcard, and parsers will be able to put them together. Only one address will be generated inside a vcard, and it will include all sub-attributes declared in distinct elements labeled as 'adr'. --Qyd (talk) 18:19, 24 August 2008 (UTC)[reply]

No, I have not interpreted the specification wrongly; and nothing in the part you cite contradicts what I have said. Of course ADR can occur more than once; because someone can have more than one address (their home, their workplace, their weekend cottage in the country, or wherever). But each occurrence is a different address. Please find us, if you can, the part of the specification which says that separate addresses are to be combined in the manner you imagine; and which says what should happen if one address had a country-name of, say, England, another of Brazil. Andy Mabbett | Talk to Andy Mabbett 18:27, 24 August 2008 (UTC)[reply]

Each occurrence is not a different address. While the documentation is not specific about that, the behavior of any vcard content extractor is very clear: only one address is generated per vcard, and distinct elements (inside a vcard, but in separate adr elements) are merged. Duplicate fields are replaced by the last declaration (as it happens with most html declarations). Please try Firefox operator in User:Qyd/Temp and see what happens, or try the external http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=http://en.wiki.x.io/wiki/User:Qyd/Temp to see the effect. --Qyd (talk) 01:58, 27 August 2008 (UTC)[reply]

Do you understand the difference between an authoritative or normative SPECIFICATION and a "broken" implementation? There are other implementations besides the Operator extension, which behave differently. Please see: http://microformats.org/wiki/hcard#Property List, specifically:

adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
...
adr tel email types
The following lists are informative. See RFC2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values.
They are repeated here for convenience.
Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.
*adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref

which says that multiple INTL, POSTAL, PARCEL and WORK addresses can be included in a hCard/vCard, along with only one dom, home, and pref address. i.e. an organization or person has only ONE "home" address and they have only ONE "preferred" address, and the home address can be different than the preferred address.

and http://microformats.org/wiki/hcard-profile which says:

   <dt>adr</dt>
    <dd>See section 3.2.1 of RFC 2426.</dd>"

and http://microformats.org/wiki/adr which says:

adr (pronounced "adder"; FAQ: "why 'adr'?") is a simple format for marking up address information,
suitable for embedding in HTML, XHTML, Atom, RSS, and arbitrary XML.
adr is a 1:1 representation of the adr property in the vCard standard (RFC2426 (http://www.ietf.org/rfc/rfc2426.txt)) in HTML,
one of several open microformat standards. It is also a property of hCard.

Which say that RFC 2426 is the standard on which hCard/vCard adr is based (1:1 representation) ...

http://www.ietf.org/rfc/rfc2426.txt goes on to say:

3.2.1 ADR Type Definition
...
   Type special notes: The structured type value consists of a sequence
   of address components. The component values MUST be specified in
   their corresponding position. The structured type value corresponds,
   in sequence, to the post office box; the extended address; the street
   address; the locality (e.g., city); the region (e.g., state or
   province); the postal code; the country name. When a component value
   is missing, the associated component separator MUST still be
   specified.
...
   The TYPE parameter values can include "dom" to
   indicate a domestic delivery address; "intl" to indicate an
   international delivery address; "postal" to indicate a postal
   delivery address; "parcel" to indicate a parcel delivery address;
   "home" to indicate a delivery address for a residence; "work" to
   indicate delivery address for a place of work; and "pref" to indicate
   the preferred delivery address when more than one address is
   specified.
...
   This type is based on semantics of the
   X.520 geographical and postal addressing attributes.
...

NOTE: specifically "WHEN MORE THAN ONE ADDRESS IS SPECIFIED", and while HTML/XML microformat tagging permits omitting blank or empty components, The REQUIREMENT that EACH AND EVERY ADR be composed of: (post office box, extended address, street address, city/locality, province/region/state, postal code, country) has NOT changed.

Personally, I do not feel that adr microformat fields should be rearranged from their X.520 or RFC 2426 semantic order or sequence, but I am not going to argue that semantic point here, and for parsing purposes: an adr microformat reader "could" rearrange adr tagged fields "back into the appropriate order or sequence"; my point would be that they normally should be in the appropriate (X.520/RFC 2426) sequence unless there is a good technical reason not to.

So:

adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name)

is properly formed.

Whereas adr( region ), adr( postal-code ), adr (country-name) are all MALFORMED;

and hCard/vCard permits including or specifying more than one address, like:

vcard( fn org()
 adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, home)
 adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, work)
)

NOTE: types like home or work are coded as:

Either:
< ... class="type">home</ ...>
or
< ... class="type">work</ ...>

within the corresponding < ... class="adr"> ... </ ...>

Flat-out:

vcard( fn org() adr( a b c ) ) is correct usage
whereas vcard( fn org() adr(a) adr(b) adr(c) ) in INCORRECT usage (where a b c are "components" of ONE address),
and vcard( fn org() adr( a1 b1 c1 ) adr( a2 b2 c2 ) ... ) is permissible (i.e. multiple addresses),

where a1 b1 c1 are components of the 1st address, and a2 b2 c2 are components of a 2nd address, ...

LeheckaG (talk) 06:43, 27 August 2008 (UTC)[reply]

So when more then one address is specified, type must be defined, and that's how parsers detect different addresses inside a vcard. Now if they're defined in more then one place, they would still be recognized (the codes "vcard( fn org() adr1( a1 b1 c1 ) adr2( a2 b2 c2 )" would generate the same microformats as " vcard( fn org() adr1( a1 b1) adr2(b2 c2 ) adr1( c1) adr2( a2)" ). One of the examples I've given comes from one of the microformat developers site, and it does merge split declarations. Can you please find any kind of error message or a "broken" extracted microformat to go with your theory? If not, than please acknowledge that the lengthily text above is just your interpretation. --Qyd (talk) 13:45, 31 August 2008 (UTC)[reply]

So when more then one address is specified, type must be defined - No. Where in the specification do you think that is mandated? Andy Mabbett | Talk to Andy Mabbett 14:22, 31 August 2008 (UTC)[reply]

That's what LeheckaG says above. I agree with that, it's similar to the "tel" class. Otherwise there's no way in hell it would work. If you know otherwise, please provide example. Thanks. --Qyd (talk) 21:10, 1 September 2008 (UTC)[reply]

No. If you think that's required, please point to the relevant part of the specification; as I have already asked you to do. I cannot prove a negative. Andy Mabbett | Talk to Andy Mabbett 21:23, 1 September 2008 (UTC)[reply]

You still haven't provided any example of what you called broken microformat (other than theoretical speculation), any kind of error message, I'm asking you to give any kind of prove that it was broken. I don't want to play this silly game, I'm just sorry that the possibilities offered by microformats are not fully implemented because of someone stubborn like you. Too bad. Peace out. --Qyd (talk) 04:25, 3 September 2008 (UTC)[reply]

I take it from your aggressive tone that you can't find support for your position in the ADR microformat spec. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 08:17, 3 September 2008 (UTC)[reply]

Other issues

Yes. 1 of the few or several? "problems" is that class="adr" should "div" or "span": (country-name, region, and postal-code); rather than being applied separately to each "adr" component. See below (copy and pasted from edit conflict warning):

Talk about "... opening a can of worms ..."; I had wondered about the <th class="adr"> ... <span class="country-name"> ... <span class="region"> ... <span "class="postal-code"> edit when I saw it on my watchlist. <span class="region"> had caught my attention, and when I had previously researched it, I could not find "region" in MediaWiki:common.css nor MediaWiki:Monobook.css. So initially, I believed what was "broken" is that the Cascading StyleSheet (CSS) class "region" does not exist for at least most English Wikipedia users with "default" (Monobook.css) preferences. I do not know if any of those CSS classes might exist in any of the other Wiki "Skins"?

Specifically, see Wikipedia:Skin, Help:Cascading style sheets, and Wikipedia:Catalogue of CSS classes

The claim is that the English Wikipedia uses these .css files in this cascade order:

I only searched for (CSS class) "region", which I did not find in any of those CSS (Cascading Style Sheet) files.

a "View, Page Source" in a web browser roughly confirms use of those Cascading Style Sheets, but apparently there are other undocumented ones as well.

http://www.ietf.org/rfc/rfc2426.txt is the authoritative/normative reference standard on which microformats are based; microformats are a 1:1 mapping between the RFC 2426 vCard MIMI profile or structure and the corresponding XML/CSS markup, see: http://microformats.org/wiki/hcard-profile which specifies the hcard/vcard mapping; although some microformats may have diverged in actual practice a little bit since (although they probably should not have).

XML Microformat markups say to use < ... class="">, but then they do not go on to say strongly enough that the shared Cascading Style Sheets (CSS) should be updated with the appropriate class(es) to support those corresponding microformats. Nor do they go on to caution strongly enough about the appropriate "nesting" structure of the microformats. Although <... class="non-implemented-class"> might work, good coding practice is that the corresponding Cascading Style Sheet should be updated to indicate the use of the class, even if it is just with a "blank placeholder". Also generally, classes should NOT be concatenated, i.e. each microformat < ... class="tag"> should NOT be merged into < ... class="tag1 tag2 tag3">. < ... class="fn"> is the 1? notable exception where classes/tags such as < ... class="fn org"> is valid.

So "vcard" should stand as its own outer envelope < ... class="vcard">, rather than being merged with other < ... class="tag1 tag2 tag3">.

So the 1st. "obvious" thing which I see is that < ... class="adr"> should NOT be applied separately on "country-name", "region", and "postal-code". Rather < ... class="adr"> should be an outer "envelope" or "container" encompassing the address's inner components.

Per http://microformats.org/wiki/adr, Within < ... class="adr">, permitted "types" are: post-office-box, extended-address, street-address, locality, region, postal-code, country-name.

Note that a "raw" adr is "out of context", for example saying "42" here would mean? Whereas saying it in the context of "Hitchhiker's Guide to the Galaxy" would mean something totally different than saying "42" in many other contexts. So an "adr" must or should be contained within another microformat like http://microformats.org/wiki/hcard (a.k.a. class="vcard" ... class="fn org" ...) for which it is the address of.

Similarly, within a microformat < ... class="type"> container or envelope, EVERYTHING should be appropriately structured and tagged, so fields which are NOT appropriate to the microformat either need to outside of such microformat containers or envelopes or they need to be tagged with appropriate tags which effectively "comment them out" for the microformat purposes, while still having their normal effect(s) otherwise. RFC 2426 vcard specifies a "NOTE", for which there does not appear to be a conflicting class in MediaWiki:Common.css or MediaWiki:Monobook.css. So a < ... class="note"> could be used to effectively "comment out" other XML components (while they still retain their original effect) when they are not really a component of the corresponding microformat. Class "note" should be added to either MediaWiki:Common.css or MediaWiki:Monobook.css to "document" and "placemark" it so that it is used appropriately and not subsequently used to do something else.

A "problem" which < ... class="adr"> "creates" is that the corresponding Infobox fields should be reorganized so that the "adr" component fields are within the corresponding < ... class="adr"> container or envelope.

So either: MediaWiki:Common.css or the corresponding skins (Monobook.css, ...) should be updated with the appropriate CSS code to document or implement those classes, even if they are blank/empty.

And < ... class="adr"> should be moved so that while it is still within << ... class="vcard"> and < ... class=fn org">; that ... class="adr" ... is a container or envelope surrounding < ... class="country-name" ... class="region" ... class="postal code">.

LeheckaG (talk) 10:43, 22 August 2008 (UTC)[reply]

With regard to "reversing" or "reverting" the edit originally cited which "broke" the "vcard"-"fn org" Micro-format. In my opinion, it should not be reverted, but rather appropriately updated so that < ... class="adr"> encompasses the corresponding adr sub-fields collectively rather than individually. LeheckaG (talk) 10:50, 22 August 2008 (UTC)[reply]

Sadly, that doesn't seem to be possible, with current methods of template construction. Andy Mabbett | Talk to Andy Mabbett 11:11, 22 August 2008 (UTC)[reply]

Huh? it means reorganizing the "adr"-related (country-name, region, and postal-code) fields so that they are adjacent to each other rather then spread out in the Infobox, and then placing the class="adr" so that it is a container around the block. If it is an "address", then it should "look like an address", i.e. adr(name, street, city, state, county) which means rearranging the Infobox fields.

You unfortunately make some fundamentally wrong assumptions about microformats, and HTML in general. In HTML, classes may legitimately be used, without reference to stylesheets. That said, it may be worth adding the relevant classes (more listed in {{UF-hcard-geo}} and {{UF-hcard-person}}) to the relevant CSS files; even if only in a comment. I see no reason why VCARD should not be on the same level as other classes, nor why classes should not be concatenated on a single element in general - that's perfectly acceptable and valid mark-up; it avoids bloat (or "DIV-itis"). There is no requirement, in microformats, to "comment out" other data; anything not explicitly encoded in a child-class is ignored; using class="note" would INCLUDE that data in the microformat. ADR microformats need not be contained within another microformat (though often are); but should only be used to mark up addresses, not other data. (This discussion might be better placed on {{ProjectMicroformats}}; which you're welcome to join.) None of this affects the above "editprotected" request. Andy Mabbett | Talk to Andy Mabbett 11:26, 22 August 2008 (UTC)[reply]

Not exactly. Yes, one can use class="undefined-style", but that is generally not a good idea, and while HTML/XML class style rules can be added or defined outside of stylesheets like on "normal" HMTL/XML pages (outside of Wiki), it was my understanding that the WikiText parser does not let a contributor add or define a CSS style rule: tag.name { property: value } outside of the appropriate User:*.css stylesheets? So that on Wiki, CSS styles should be added on the MediaWiki:Common.css or appropriate skin MediaWiki:Monobook.css. Is that not true about WikiText? or can Wiki Article, Template:, Project, or User: pages include page-specific CSS style rules (i.e. defined on the article page rather than on a separate common stylesheet)? If that is indeed possible, then the Infobox Settlement template could or should "self-defined" those microformat CSS style rules which are not defined elsewhere which it uses at the beginning of the template.

The "problem" which I see with the classes used as microformat tags not being listed on MediaWiki:Common.css is that someone could come along later and add a shared CSS style rule with any of those names, possible causing "unfortunate" side effects or page rendering - which is why style classes used as common microformat tags should be centrally defined on Wiki.

Microformats have a "structure to them". adr(country-name), adr(region), adr(postal-code) means something different than adr(country-name, region, postal-code).

Yes, [http://microformats.org/wiki/hcard-parsing] allows for a microformat's root element (like hcard's class="vcard" to be concatenated along with other CSS classes.

Elsewhere they do not clearly indicate whether subsidiary components within vcard can be concatenated or not, although none of the examples show concatenation of other tags [http://microformats.org/wiki/hcard-examples-rfc2426] and the DTD [http://microformats.org/wiki/hcard-profile] indicated them as separate, nor does the microformat parsing description discuss concatenated non-root tags other than "fn".

there is considerable discussion regarding the "fn" element (fn n, fn org, ...) which generally seems to indicated not.

Any markup divisions should reflect the semantics, like: "correct" vcard( fn org( adr(a, b, c) ) ) versus "probably incorrect" vcard( fn org( adr(a) adr(b) adr(c) ) ); or "definitely incorrect": vcard( fn org( ) adr(a) adr(b) adr(c) ) or likewise incorrect vcard( ) fn org( ) adr(a) adr(b) adr(c)

LeheckaG (talk) 16:57, 22 August 2008 (UTC)[reply]

I would like to understand if I missed something regarding Help:HTML in wikitext and <style type="text/css"> tag.name { property: value ; ... } </style> rules on a WikiText HTML/XML page rather than in a separate Wiki stylesheet (WikiMedia:Common.css, WikiMedia:Monobook.css and the other Wiki "Skins", User:*.css), but from my quick "SandBox" testing, it appears that WikiText behavior matches the HTML in WikiText documentation, and ignores the <style type="text/css"> and </style> HTML/XML tags, so am I missing something? LeheckaG (talk) 21:18, 22 August 2008 (UTC)[reply]

I'm not sure what you're asking, but I think you need to ask on a more appropriate talk page. Andy Mabbett | Talk to Andy Mabbett 21:27, 22 August 2008 (UTC)[reply]

YOU said "... fundamentally wrong assumptions ..." so what exactly are you referring to? When I make a mistake, I prefer to understand what it is. As it currently stands, either the adr, country-name, region, and postal code update should be reverted as someone else originally requested; or the template should be updated so that the "adr"-related fields are re-grouped together in the proper order ...

(as far as I know "English": US, Canada, England, Australia, ... addresses are in that order and grouping - versus some non-English addresses which flow in the opposite direction, like Russia)

<span class="adr">
{{#if:{{{subdivision_type1|}}}|
	<tr class="mergedrow">
		<th>{{{subdivision_type1}}}
                <th><span class="region">{{{subdivision_name1}}}</span>
	</tr>
<!-- ***** Subdivisions ***** -->
{{#if:{{{subdivision_type|}}}|
	<tr class="mergedtoprow">
		<th>{{{subdivision_type}}}
                <th><span class="country-name">{{{subdivision_name}}}</span>
	</tr>
<!-- ***** Postal Code(s) ***** -->
{{#if:{{{postal_code_type|}}}|
	<tr class="mergedtoprow">
                <th>{{{postal_code_type}}}</th>
                <td><span class="postal-code">{{{postal_code}}}</span>
	</tr>
</span>

I know that there is more to it than that (that there are other adr-related fields, and re-ordering visibly displayed fields in a protected Infobox is a change which requires consensus). So for now those "adr" changes should probably be reverted until it can be done a better way, the multiple separate "adr" is definitely broken. LeheckaG (talk) 22:16, 22 August 2008 (UTC)[reply]

Nobody is asking for " re-ordering visibly displayed fields". The "regrouping" you propose is not possible, as I have already said - and you cannot wrap a span around multiple table rows. I addressed your "fundamentally wrong assumptions", but this is not an appropriate place to discuss them, as they are either not specific to, or mostly not relevant to, this template. Andy Mabbett | Talk to Andy Mabbett 22:34, 22 August 2008 (UTC)[reply]

What was asked for was fixing the "3" address problem (each with only a piece of the address) with a proper adr microformat which implies vcard( fn org( adr(region, country-name, postal-code) ) ) rather than the "3 address": adr(region), adr(country-name), adr(postal-code). Actually the re-grouping is possible, yes, while WikiText parsing and re-writing of HTML/XML breaks "span" when it encounters certain table elements, what does work is re-grouping those adr-related rows together and splitting them into either a separate or nested table and placing a div or similar around that:

either:

<table>
 ... top of table ...
</table>
<div class="adr">
 <table>
  ... relevant rows ...
 </table>
</div>
<table>
 ... bottom of table ...
</table>

or

<table>
 ... top of table ...
 <div class="adr">
  <table> <!-- nested table -->
   ... relevant rows ...
  </table> <!-- end of nested table -->
 </div>
 ... bottom of table ...
</table>

and yes, I understand that WikiText parsing and re-writing of the latter actually breaks out the div and nested table, effectively creating something similar to the table - table - table layout above rather than remaining nested.

"Think outside of the box" and no you did not say what is wrong, just that you are apprarently either unwilling or technically incapable of fixing the issue, while there "always" is some way, I understand that WikiText might not make some things easy and has more restrictions than "normal" HTML/XML. LeheckaG (talk) 01:34, 23 August 2008 (UTC)[reply]

With regard to an adr microformat being used stand-alone, while Wikipedia "informative" HCard says "The adr part of hCard can also be used as a stand-alone microformat.", the actual adr microformat authoritative/normative specification http://microformats.org/wiki/adr says "If the publisher knows and is publishing the name of the location in addition to its address, then the publisher MUST use hCard instead of just adr to publish the name and address of the location." Note the "MUST" which means that in most cases hCard (a.k.a. vcard) MUST be used instead of a stand-alone adr unless you somehow have an address but have no clue as to what it is the address of? LeheckaG (talk) 02:08, 23 August 2008 (UTC)[reply]