Jump to content

Wikipedia talk:Requests for comment/Microformats

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Response to SarekOfVulcan and subsequent discussion

[edit]

I've been trying to determine how microformats are useful to the average reader, but haven't really been given any concrete examples. Could you provide some? –xenotalk 13:46, 10 August 2010 (UTC)[reply]

Sure. How about this one? --SarekOfVulcan (talk) 13:54, 10 August 2010 (UTC)[reply]
Thanks. Stuff like this is exactly what should be presented when discussing individual implementations of microformats. I still don't think they should be added to a template unless a demonstrable benefit is presented. –xenotalk 14:00, 10 August 2010 (UTC)[reply]
But if we had not geo-tagged articles, Google would not have been able to do that. This is about enabling the future. Jack Merridew 00:27, 11 August 2010 (UTC)[reply]

[moved from project page] I would like to point out that as far as I know, Google doesn't use our microformats to retrieve this geodata. They just parse wikicode from the database backups of Wikipedia looking for {{coord}} and similar templates. At least that's how Dschwen explained it to me once. —TheDJ (talk • contribs) 13:16, 11 August 2010 (UTC)[reply]

To reiterate the comment I made in my endorsement of SarekOfVulcan's view: this Google document, reuses all the microformats from a single Wikipedia article, via one of the third-party tools for manipulating this supposed "as-yet-unproven technology", which statements [in the RfC's "views"] allege don't exist(!). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:47, 11 August 2010 (UTC)[reply]
The fact you have to use a third party tool to do it, pretty much sums up the fact that its unproven yet, because none of the major players support it natively. -DJSasso (talk) 13:54, 11 August 2010 (UTC)[reply]
Poppycock! That's exactly what is intended to be done (though that's not to say that Wikipedia couldn't replicate those third-party tools, which are generally open-source, internally). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:01, 11 August 2010 (UTC)[reply]
I was actually referring to web browsers. If the technology was proven all of them would support microformats without the need for plugins or third party applications. Generally browsers do not support new web technologies natively until they have been proven. So lack of support from IE, Firefox tends to point towards an unproven technology that might never actually come into mainstream use. -DJSasso (talk) 14:03, 11 August 2010 (UTC)[reply]
Firefox has a native microformats API. Ooomph', a microformats plug-in for IE, is provided by Microsoft. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:08, 11 August 2010 (UTC)[reply]
Again plugins/apis. Which means neither has the confidence in them yet to support them natively. -DJSasso (talk) 14:12, 11 August 2010 (UTC)[reply]
That isn’t at all how browser vendors work—HTML5 support is being added by all browsers and it’s not even last call, let alone a completed W3 standard. By this logic Flash isn’t proven either. Finally microformats are already in mainstream use regardless of native browser support — Oli Studholme (talk) 14:15, 22 August 2010 (UTC)[reply]
As far as I can see, all that uses is the coordinate data, which Google can use anyway, without the microformats. There are no contact details, calendar events or recipes anywhere to be seen. OrangeDog (τ • ε) 13:54, 11 August 2010 (UTC)[reply]
Show me how. Show me how Google can also extract the data as RDF, or KML, etc., as that and other such tools (whose existence is still denied on the RFC page) can. There is no "calendar event or recipe" on our page about the Tame Valley Canal. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:00, 11 August 2010 (UTC)[reply]
The point is, we all agree that what {{coord}} does is a good thing. Continuing to argue that it's good is a waste of time. OrangeDog (τ • ε) 14:47, 11 August 2010 (UTC)[reply]
I'm sure we do agree that; but that is not my point, so please refrain from dismissing it as such. my point was to refute the false allegations that "microformats are an as-yet-unproven technology", and yours that "there are currently no user applications that make meaningful use of our microformats" and "this is redundant to our existing {{coord}} system" [albeit that {{Coord}} was create to and still does emit a geo microformat]. I note that you did not respond to my question about RDF & KML, etc. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:52, 11 August 2010 (UTC)[reply]
Just noting that these examples still don't show us how metadata is useful to Wikipedia readers. I guess that means that they aren't (presently), but are useful to external tools and users thereof? –xenotalk 16:12, 11 August 2010 (UTC)[reply]
Links to such services are available, from our articles, to such services. They are thus of use to Wikipedia's readers. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:52, 11 August 2010 (UTC)[reply]
They are useful to the the indirect Wikipedia readers who use such services (which can themselves also be considered "readers"). --Cybercobra (talk) 00:30, 15 August 2010 (UTC)[reply]

Response to Jarry1250 and subsequent discussion

[edit]

Note: The view being discussed has since been "retract[ed] on basis of more substantive concerns raised [in subsequent views]"

The problem as I see it, is that in a number of cases with templates, in order to make microformats work, we often have to sacrifice how the information is displayed and layed out on wikipedia. Which means in order to have microformats we have to hurt how we would normally display the information and/or cut out information completely. So we harm the majority of users to suit the desires of the minority of users. -DJSasso (talk) 14:18, 10 August 2010 (UTC)[reply]

Indeed, I mentioned {{duration}}; a template recently created by Pigsonthewing (talk · contribs), who is asking for a bot to deploy it across song articles so that metadata may be emitted. –xenotalk 14:28, 10 August 2010 (UTC)[reply]
I notice that HCalendar is described as causing accessibility problems (abbr element) and that some workaround is being sought. I don't know enough about this to tell if Wikipedia can avoid this problem in our implementation, but it obviously our priorities for accessibility should put disabled users ahead of techno-toys. Wnt (talk) 14:54, 10 August 2010 (UTC)[reply]
Thanks for the note. Since it will influence my position a fair bit, I have removed my "view" pro tem (it's still available in the page history). It's the substantive concerns that are coming out into the open now that interest me, and it would be wrong for me to appear fixed. Regards, - Jarry1250 [Humorous? Discuss.] 15:34, 10 August 2010 (UTC)[reply]
As the person who first raised the issue of the accessibility of mis-using ABBR in hCalendar and lobbied for a better method I made sure, when I introduced hCalendar to Wikipedia, that it did not use that technique. Our hCalendar and other microformats microformats do not have accessibility issues. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 10 August 2010 (UTC)[reply]
Indeed you did mention {{duration}} - though it is misleading of you to do so here, since it neither "hurts how we would normally display the information nor "cuts out information completely". More FUD. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 10 August 2010 (UTC)[reply]
DJSasso can you provide examples of where we "have to hurt how we would normally display the information and/or cut out information completely" due to the presence of microformats? the claim that microformats "harm the majority of users" is utterly, utterly bogus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:41, 10 August 2010 (UTC)[reply]
I recall one example where a field would have needed to be broken up into several different parts in order to provide the metadata you wanted. –xenotalk 15:52, 10 August 2010 (UTC)[reply]
Cite? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:25, 10 August 2010 (UTC)[reply]
Do you? –xenotalk 16:29, 10 August 2010 (UTC)[reply]
I to seem to remember Andy having that very conversation for some field. You couldn't have the information all in one field because it needed to be seperate for use in microformats. -DJSasso (talk) 16:27, 10 August 2010 (UTC)[reply]
For example, this, discussed here. OrangeDog (τ • ε) 16:38, 10 August 2010 (UTC)[reply]
Ahh yes, all the uproar surrounding the Brussels one. That is the one I was thinking of. -DJSasso (talk) 16:41, 10 August 2010 (UTC)[reply]
Thanks, I believe that's what I was vaguely recalling: that in order to allow microformats to be added, we would have to do away with inline referencing in the infobox, or somesuch. There is also this lengthy discussion which I've only skimmed (apparently some complications were caused by supporting microformats). –xenotalk 16:45, 10 August 2010 (UTC)[reply]
"in order to allow microformats to be added, we would have to do away with inline referencing in the infobox, or somesuch" Yet another false, unsubstantiated claim.
Your lengthy discussion reference contains nothing to suggest that microformats are not useful; the only complications were caused by the misapplication of a microformat, since resolved. Scraping the barrel already? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:42, 10 August 2010 (UTC)[reply]
As I said, I only briefly skimmed it. Are you going to offer a view, or simply harangue users here on the talk page? –xenotalk 18:51, 10 August 2010 (UTC)[reply]
So you did perhaps in future you could do us the courtesy of reading things before offing them as evidence to support your misguided arguments? I'm not haranguing anyone, but nor am I going to offer a view. I'll provide facts, in my own time not yours, and refute false claims as often as you or anyone else makes them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:00, 10 August 2010 (UTC)[reply]
What false claim? –xenotalk 19:05, 10 August 2010 (UTC)[reply]
How interesting that you cite that edit, but not my subsequent rebuttal of it (it related to the moving of a duplicated reference, and the removal of a reference which did not say what was claimed). How interesting that it refers not to content, but templated metadata (which is what references are). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:00, 10 August 2010 (UTC)[reply]
Actually, the thread ended due to inactivity; you hadn't responded to the Fram's rebuttal. –xenotalk 17:07, 10 August 2010 (UTC)[reply]
That was no rebuttal; merely a couple of examples of bad practise. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:37, 10 August 2010 (UTC)[reply]
In your opinion. –xenotalk 18:51, 10 August 2010 (UTC)[reply]
No, as matter of fact, as any fool can see. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:00, 10 August 2010 (UTC)[reply]
Too bad we're not fools then. OrangeDog (τ • ε) 21:13, 10 August 2010 (UTC)[reply]
Is there a guideline prohibiting inline references in infoboxen? –xenotalk 19:05, 10 August 2010 (UTC) (Apparently not)[reply]

This sort of technical problem would be greatly eased if we had access to the proper string functions. Rich Farmbrough, 23:52, 25 August 2010 (UTC).[reply]

Question

[edit]

Given that Xeno now thinks that "a general discussion or policy about whether to use or not to use microformats as a matter of principle is … not very helpful" and that "microformat opponents should approach each case individually with an open mind rather than letting this become a factional dispute" is "eminently reasonable", will he now withdraw this unhelpful and factional RfC? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:06, 10 August 2010 (UTC)[reply]

You've cherry picked from a much lengthier statement (I've since expanded my endorsement). When did I ever say I was a microformat opponent? I said in this very RFC that I think they should only be added when there is a clear advantage and benefit to our reader [1]. If the proponents of microformats were to present their editprotected requests to add microformats with an exposition of how they would be useful, rather than simply demanding they be added "because there was consensus formed three years ago!" (that they are unable to link to) then they might encounter fewer objections to their requests. If this RFC convinces microformat proponents to be less strident in their quest to emit microformats from every template imaginable, then it will have succeeded. ("...metadata mechanisms should never get in the way of reading or writing Wikipedia and should not become mandatory. The balance between the cost and the benefit of using metadata mechanisms varies with each use case ... their merits should be discussed and consensus for their use should be sought on a case-by-case-basis... Microformat advocates should temper their boldness with respect for our expectation that wide-ranging changes require consensus before implementation." is what I found eminently reasonable) –xenotalk 22:12, 10 August 2010 (UTC)[reply]
I didn't cherry pick, I simply pointed out what you had endorsed; and the inherent contradiction in your position, Now you've realised that, you've revised your statement. Your "quest to emit microformats from every template imaginable" is, once again, unsubstantiated hyperbole. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:27, 10 August 2010 (UTC)[reply]
I was compelled, as you picked two sentences out of a three paragraph statement to arrive at a spurious conclusion. –xenotalk 22:29, 10 August 2010 (UTC)[reply]
Why don't you actually try to work with people to find a workable solution instead of berating users and being generally disruptive? -DJSasso (talk) 22:32, 10 August 2010 (UTC)[reply]
I have been doing so - in regard to microformats in particular - for at least three years, including but not limited to, centralised discussion, staring a project, notifying and working with relate related projects, BOTREQs and proposals on VPP & VPT. Why don't you you actually try to work with people to find a workable solution? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:40, 10 August 2010 (UTC)[reply]
That's what this RFC is...the centralized discussion that has up to this point never happened despite your constant claims that one has. You want microformats to be used, then take part in this RFC in a civil manor and comment on the issue not the editors as you have been doing with xeno. -DJSasso (talk) 22:44, 10 August 2010 (UTC)[reply]
My conclusion was that by writing "Eminently reasonable" under Sandstein's view, in the section labelled "Users who endorse this summary", you endorsed Sandstein's view. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:42, 10 August 2010 (UTC)[reply]
I'll be sure to wax poetical in the future; I mistakenly thought it would be patently obvious I felt a general discussion was helpful, having initiated one. –xenotalk 22:47, 10 August 2010 (UTC)[reply]
Andy, jumping on a little point like this is looking more and more like wikilawyering. Clearly xeno didn't mean to endorse that portion of Sandstein's comment, and told you this clearly, and even modified the endorsement to reflect that. Highlighting that doesn't win any "points" here. What you need to do is convince people why microformats are important to include, and illustrate what benefit they give. I like new technology, I love cool new tricks for web pages, and I like to think I'm open-minded. I'm definitely not opposed to the idea of microformats, but I don't want to change the way pages are edited to accommodate this new technology unless I can see why it's necessary (or at least useful). -- Atama頭 23:22, 10 August 2010 (UTC)[reply]

Duration

[edit]

The number of people agreeing that

"In some cases (e.g. {{Duration}}), existing style, flexibility and guidelines must be violated in order to correctly emit microformats"

when no such violation occurs, much less by {{Duration}}, is worrying. How can this discussion be meaningful, when such falsehoods are accepted unthinkingly? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:35, 10 August 2010 (UTC)[reply]

For example, the sample edit you gave removed the day from the release dates, as well as greatly increasing the page source complexity. The examples of microformat templates requiring infobox fields to be split up have already been given. OrangeDog (τ • ε) 22:53, 10 August 2010 (UTC)[reply]
The former occurred because I inadvertently typed {{Start date|1973|05|07df=y}} and not {{Start date|1973|05|07|df=y}} (note pipe character) - a typographical error, in a very widely-used template, easily fixed, and certainly not a "violation of existing style, flexibility and guidelines". The remainder of that edit involve no grater - indeed, far less - complexity than, say, {{Convert}}. If infobox fields are split that also is not a "violation of existing style, flexibility and guidelines". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:19, 10 August 2010 (UTC)[reply]
It is irrelevant to compare it to other templates. There used to be no templates there; you just typed what you wanted to see. Now you have to use a series of complex templates. If you do not believe they are complex, then the fact that their creator failed to use them correctly in the edit he used as a sample for a bot request should demonstrate that they are not non-trivial.
Another question is why you want to add them to every separate use of that infobox in every article, instead of just making one invisible change to the template. Perhaps because you tried that and WP:ALBUMS/WP:SONGS didn't want it? OrangeDog (τ • ε) 11:24, 11 August 2010 (UTC)[reply]
It is not irrelevant to compare {{Duration}} to other, similar, templates; the comparison illustrates that such templates can and do work, and are used by many editors with no serious issues. An no, you do not "have to use a series of complex templates"; you can still type the same plain text you always have, and later, someone else, or a bot, can convert to the template. Modifying the infobox will not be practical, because of cases where people include references, a second duration, or other supplementary material, as in the cases discussed elsewhere on this page. Presumably you have never made a typographical error? And your final insinuation is baseless. Why do you feel the need to make it? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:35, 11 August 2010 (UTC)[reply]
Andy, we all know you are a highly disruptive editor who refuses to listen or meaningfully engage with anyone (previous examples). This is possibly your last chance to a) provide some actual evidence for any claims or counter-claims you make, b) actually explain why you think you are correct on these matters and everyone else is wrong, c) discuss the issues in question rather that the people who discuss them or the slight ambiguities they make in discussing them. OrangeDog (τ • ε) 13:49, 11 August 2010 (UTC)[reply]
Temper, temper. Would you say it that way IRL? We share our thoughts with these machines, and they share their emotions with us, and if we don't actively weed out their mechanical sentiments, we end up ourselves feeling their profound hatred of all living things sooner than you'd think. Wnt (talk) 16:14, 11 August 2010 (UTC)[reply]
Barring threat of physical violence, yes I would. Others have said it before, hence Andy's block log. I will henceforth not talk about Andy's previous behaviour here, as that is exactly the point I was trying to make. OrangeDog (τ • ε) 16:36, 11 August 2010 (UTC)[reply]
Try addressing the substance of the concerns, rather than nitpicking the presentation. –xenotalk 23:22, 10 August 2010 (UTC)[reply]
I think part of the issue here is that Andy thinks that splitting up infobox fields, adding extra source code, and similar changes aren't a big deal and are worth it if it allows the page to emit microformats (please correct me if I'm wrong, I don't presume to put words in anyone else's mouth but that's how I perceive the argument). A large number of editors at this RFC are currently disagreeing with that assertion. I don't think this is due to ignorance on the part of those who disagree, but a fundamental difference of opinion. -- Atama頭 23:27, 10 August 2010 (UTC)[reply]
The false allegation (one of several) of "violation of existing style, flexibility and guidelines" which I'm trying to dispose of is the issue here (by which I mean this sub-section); and that people agree with such a false statement can only be from ignorance (if we discount malice and idiocy). If by "here" you mean the wider page, then my "view" is in draft. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:42, 10 August 2010 (UTC)[reply]
By "here" I do mean this subsection, sorry about the lack of clarification. Let's simplify things, in one example mentioned you seem to acknowledge that we need to split infobox fields, but doing so is not a "violation of existing style, flexibility and guidelines". I'll accept that suggestion for now to avoid getting into a debate about the MOS, etc. Even if it's allowed, I don't think editors want to be forced into having to alter infoboxes in such a manner just to allow them to emit microformats. That's where the complaint about the lack of flexibility at the least would stem from. As I'd said, you seem to insist that it's not that big of a deal (again, using the microcosm of splitting an infobox field here) and others think that it is. Personally, I don't mind giving up a little flexibility if I know for certain that doing so is actually going to be useful. And if the infobox ends up "looking worse" (a subjective determination) I want to know that it's worth it. You clearly think it is, but others don't. That's the fundamental difference of opinion. -- Atama頭 00:16, 11 August 2010 (UTC)[reply]
Have you seen any evidence (as opposed to unfounded allegations) of an infobox "looking worse" because it emits a microformat? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:58, 11 August 2010 (UTC)[reply]
There's this one, and here's a bit of advice... Please try to work on your communication skills if it's possible. You're attacking everyone with your choice of words. It's not necessary to belittle everyone you're speaking with. I'm actually trying to help here, and I'm not firmly against you, but considering that everyone who disagrees with you is a "fool", coming from "ignorance" and having nothing but "unfounded allegations". Let me be blunt... If you have any other advocates for microformats, you might want to have them assist here, because I think you're really killing your case. Part of me thinks you might be onto something and there's something to be embraced with this technology but you're continually putting me off and it's really getting difficult to talk to you. :( -- Atama頭 16:58, 11 August 2010 (UTC)[reply]
By the way, please don't take this as an attack. I'm just being honest, I'd really like to have a civil discussion and I'm legitimately curious about the potential for these microformats. -- Atama頭 18:05, 11 August 2010 (UTC)[reply]
The example you cite is not evidence of an infobox "looking worse" because it emits a microformat. Do you have evidence that I call "everyone who disagrees with me" a fool, or coming from ignorance; or having having ""nothing but unfounded allegations. Hint: no, you do not. Nor am I "attacking everyone". By making such statements, your claim that you are being honest is undermined. If your state wish to have a civil discussion is genuine, put your own house in order. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:36, 11 August 2010 (UTC)[reply]
I like to think that I have a fair amount of patience, with my experience in mediation and generally helping others on Wikipedia who don't necessarily get along with others, but I think it has been exhausted in your case. I don't feel that further discussion with you will be in any way productive. I wish you good luck with your advocacy, but it doesn't seem to be going very well. -- Atama頭 21:55, 11 August 2010 (UTC)[reply]
Refuting false allegations is not "nitpicking the presentation". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:42, 10 August 2010 (UTC)[reply]

Censorship

[edit]

…of the RfC. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:13, 11 August 2010 (UTC)[reply]

You don't get to "reserve your space". Feel free to reinstate the section when you have prepared your view. — Martin (MSGJ · talk) 11:14, 11 August 2010 (UTC)[reply]
I for one am awaiting Andy's defence of microformats and it is helpful to know that he is going to provide one. I shall now wait for it before making further comments. (I see from Opera that Andy's signature includes microformats.) It is always easy to ridicule new ideas – I was told in the early 90s that nothing would come of the internet. Occuli (talk) 13:55, 11 August 2010 (UTC)[reply]

Why not put metadata on its own page?

[edit]

I think you should create two new namespaces, Metadata: and Class:. The Metadata: space should be reserved to support articles of the exact same name (only), and should be automatically deleted when an article is deleted just like a Talk: page. The Class: space should be reserved to provide information including source links for any class used on Wikipedia. Thus "USA"'s metadata is put in Metadata:USA, and documentation for {| class="wikitable" and <span class="horizontal"> can be found at Class:Wikitable and Class:Horizontal. (I hope we never have classes distinguished by capitalizing the first letter...) These two namespaces should each have an associated talk namespace, Metadata talk: and Class talk:.

To handle metadata, you could use (for example) a template I'll call Template:Mtd, which would work like so: it contains a section of text, which is to be printed if the user does not wish to use metadata, and it links to a named parameter, which is interpreted by a switch statement in the Metadata: page to bring out the relevant metadata segment if the user desires it. (The Metadata: page's section (apart from noincludes) should consist at the highest level of {{#switch:{{{1|}}} and various subsections; the only purpose of parameter 2 is to be passed back out intact)

Thus {{mtd|track7|5 minutes 1 second}} should produce "5 minutes 1 second" normally, or (for example)"{{duration|m=5|s=1}}" if metadata is enabled by the user. Perhaps there might be several possible metadata returns depending on which capabilities the user's browser enables. (The text returned is defined by a case "|track7 = ..." in the switch statement in the Metadata: page) Note that metadata incorporated in this fashion extends the length of the page only by one "{{metd|duration|...}}" per segment if metadata is disabled.

As an outsider, I'm not entirely clear on how the user enables metadata, or whether the presence of various browser plug-ins can be sensed by your code, but I think there are some experts here who have the ability to work something out, if prodded.

I think that uninvolved parties could, with some grinding of teeth, accustom themselves to the idea that this one template might be present. Wnt (talk) 15:46, 11 August 2010 (UTC)[reply]

To show something of what I mean (except I'm not using the namespace and I don't know how to get any user preference, so it's just on by default here): "The songs Bad ( 0:07:33) and Worse ( 0:04:10) were recorded at Jack's studio at 57°18′22.5″N 4°27′32.7″W / 57.306250°N 4.459083°W / 57.306250; -4.459083.

This is generated by "The songs ''Bad'' ({{mtd|track1|7'33"}}) and ''Worse'' ({{mtd|track2|4'10"}}) were recorded at Jack's studio at {{mtd|studio|57° 18' 22.5" N, 4° 27' 32.7" W}}.

Note that editors only need to recognize one funny template, and can freely edit human readable text within it. The format has the disadvantage that someone or something needs to make sure that any chance to the human readable information is mirrored on the separate metadata page. Wnt (talk) 21:38, 11 August 2010 (UTC)[reply]

Response to Andy Mabbett

[edit]

A scraper and a parser are exactly the same thing, despite the emotive and partisan way you describe them. If microformat standards change, then likewise everyone's code will be broken. OrangeDog (τ • ε) 15:37, 14 August 2010 (UTC)[reply]

1. Parsing involves following a pre-defined standard such as a schema or specification; scraping involves analysing and reverse-engineering the structure of a specific page or site. I have clarified this in my view. 2. Microformat standards are far less prone to change than Wikipedia infoboxes. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:58, 14 August 2010 (UTC)[reply]

I don't think that marking FRD's presidency as an event that he attended, and that you can download into your calendar, is a particularly useful application. OrangeDog (τ • ε) 15:37, 14 August 2010 (UTC)[reply]

Your "download to calendar" comment is a red herring. The event can now be searched for, mapped on a timeline, converted to RDF, etc. This was not possible before the microformat was applied. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:58, 14 August 2010 (UTC)[reply]

Here is an example of microformats being harmful, in addition to the others that have been provided here and in previous discussions. OrangeDog (τ • ε) 15:37, 14 August 2010 (UTC)[reply]

Our microformats do not use and have never used the pattern described in that article, which in any case is superseded. This was explained on 10 August, in the section above, "response to Jarry1250". No such evidence has been provided. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:58, 14 August 2010 (UTC)[reply]

Given you are so clearly against others making unfounded assertions, it would be nice if you provided any evidence or logical reasoning for some of yours. Just saying that things are true, or that people are wrong, doesn't make it happen. OrangeDog (τ • ε) 15:37, 14 August 2010 (UTC)[reply]

Such as? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:58, 14 August 2010 (UTC)[reply]
Everything in your View. OrangeDog (τ • ε) 16:08, 14 August 2010 (UTC)[reply]
If you have a specific concern, I will attempt to address it. If you merely wish to mud-sling, you'll be on your own. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:12, 14 August 2010 (UTC)[reply]

{{Start date}} marks whatever it contains as bday, dtstart, published and updated. While you could, if being somewhat peculiar, describe a book as having a birthday, start date, publishing date and update time, for the most part this is exactly the kind of nonsense semantic dilution that I have been talking about. OrangeDog (τ • ε) 15:37, 14 August 2010 (UTC)[reply]

This is addressed in my "view"; also, only the applicable class is applied; if the parent is an hProduct, say, then the "bday" class, which applies only in hCard, is ignored. You can fork {{Start date}} to only emit one class in each case, if you can get consensus for that. I refer you also to Future development. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:58, 14 August 2010 (UTC)[reply]

Usability concerns

[edit]

As of now, Microformats are going on the opposite direction from current developments. The UX team is trying to make it easier to edit. Developers are building a new language to replace wikicode in templates, in order to optimize it. And where do Microformats stands? Think about long-term improvements and collaborate with these groups.

You can't accurately measure how much problems it will cause among the community yet. That's because you haven't done any user testing yet. You must take usability into account in a more serious way. Sorry I wrote that in a rush because I lack time. But in a nutshell, that's the most important things there is to say. Please use this tiny bit of information wisely. Dodoïste (talk) 22:55, 14 August 2010 (UTC)[reply]

As of now, Microformats are going on the opposite direction from current developments.
You appear to have overlooked the first point in my view. The addition of microformats is aligned with Wikimedia Foundation plans for making our content machine readable. How is that "going on the opposite direction from current developments"? Or do only your activities have any merit?
Think about long-term improvements and collaborate with these groups.
Did these groups think about long term collaborations with groups like the microformat or infobox projects? What are they doing to ensure that microformats are catered for? Or should I say: "You must take metadata into account in a more serious way"?
you haven't done any user testing yet
How did you determine that?
You must take usability into account in a more serious way.
I take usability and accessibility into account in all that I do on Wikipedia. My correspondence with Erik Möller touched on these issues, also. Please don't be so presumptuous. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:16, 14 August 2010 (UTC)[reply]
It's very easy for someone knowledgeable about usability to see that you haven't done any user testing. And that you're not familiar with usability. It shows in the way you answers the concerns of users. You don't appear to take these concerns into account like someone willing to get feedback from users. You're only saying you are right and it's the only thing that matters to you.
I don't mean to be rude or offending. I'm saying you are missing the whole point. Dodoïste (talk) 11:01, 15 August 2010 (UTC)[reply]
"I don't mean to be rude or offending.". Then you are as bad at that as you are are at determining what I do or do not know about usability. You fail dismally at both. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:14, 15 August 2010 (UTC)[reply]
I fail to see how microformats harm usability. Yes, they make the internal code in templates slightly more complex, but that's isolated within the templates' implementations themselves, which few editors touch anyway and already require significant skill to manipulate. If you want to make templates easier for the "normal" editor to edit, it's gonna take a lot more than just removing microformats. The camel's back has already been broken; one more straw won't change things significantly. --Cybercobra (talk) 00:26, 15 August 2010 (UTC)[reply]
It's precisely because the camel's back has already been broken that you shouldn't make it worse, even slightly. I'm telling Andy to introduce microformats with other usability editing improvements. Introduce microformats when the time is appropriate. Not now, obviously. Dodoïste (talk) 11:05, 15 August 2010 (UTC)[reply]
You seem to be under a misapprehension; we already emit millions of microformats, from thousands of templates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:11, 15 August 2010 (UTC)[reply]
I know. Like CoinS in {{Cite}}. It doesn't answer my concerns. It's not because it's already used here and there that it's good usability-wise. Where is your proof? Dodoïste (talk) 11:24, 15 August 2010 (UTC)[reply]
You clearly don't know. COinS is not a microformat, and is not within the scope of the RfC. You're the one making vague and unsubstantiated allegations; you prove them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:28, 15 August 2010 (UTC)[reply]
Fair enough. Employ me, I'll do some user testing on Wikipedians used to edit templates (which is our target here). And then, if results shows it makes it harder to edit templates what will you do? Dodoïste (talk) 17:11, 15 August 2010 (UTC)[reply]
"Employ me". Yeah, right. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:24, 15 August 2010 (UTC)[reply]

Use of class attribute

[edit]

[moved from project page]

Where I say semantic meaning of html/css classes, Andy refutes this interpretation in his view, based on the fact that "For general purpose processing by user agents." is a valid usage of a HTML class. I agree with that, I agree that in the widest interpretation of the accepted uses for class this is absolutely true. However, my point is that this default free-for-all idea of HTML classes is simply a bad reason to hijack it for adding semantic metadata. HTML5 seems to agree with me and is targeting Microdata atm. Hopefully this clarifies the point I was trying to make in 1. —TheDJ (talk • contribs) 23:47, 14 August 2010 (UTC)[reply]

I refute it in reference to the HTML spec and discussion elsewhere. Your claim about HTML5 is mistaken; as I already say in my view, "Microdata (for good or bad) is explicitly specified to exclude use in generic data exchange such as that discussed here" (it's also not part of HTML5). The HTML5 spec is even more clear than that of HTML 4, that class is to be used for semantic meaning: "authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:15, 15 August 2010 (UTC)[reply]

Concerns

[edit]
[Microformats] can substantially increase the size and complexity of the template; unnecessarily complicating our templates
Unsubstantiated assertions. Templates exist specifically to contain (sometimes complex) markup and coding, so that our editors need not be exposed to them.
So you agree that they become more complicated then. And logically therefore harder to understand and maintain, and require more processing time and parser nodes. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
No. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
...burdening editors with having to use things like for song lengths
False. Use of {{duration}} is optional, and editors can still enter plain text if they prefer - other editors or bots can make the substitution later, as already happens with, for example, {{Convert}} or {{Birthdate}}/ {{Birth date and age}}.
But once they've been added the wikitext of the article becomes more complicated. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Barely; and the use of template like {{Convert}} {{Birth date and age}}, etc., as I have already pointed out more than once, indicates that editors are well able to cope. This is not an RfC about the removal of templates from Wikipedia. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
Every class used in a Wikipedia template should be readily traceable to the source of the relevant extension that defines it; microformats silently reserve lots of class names
Classes are not "defined by an extension". However, see Wikipedia:WikiProject Microformats/classes and Wikipedia:Catalogue of CSS classes
What this means is we are prevented from using innocuous-looking class names as they would conflict with the microformats. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
No, it does not mean that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
What else does "microformats silently reserve lots of class names" entail? OrangeDog (τ • ε) 23:34, 15 August 2010 (UTC)[reply]
It doesn't appear to mean anything. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:54, 15 August 2010 (UTC)[reply]
What this means is we are prevented from using innocuous-looking class names as they would conflict with the microformats. OrangeDog (τ • ε) 10:17, 16 August 2010 (UTC)[reply]
No, it does not mean that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:52, 16 August 2010 (UTC)[reply]
What Andy is not explaining is that on the HTML side microformat class names are only applicable when on children elements of a container class designating the microformat. These have unusual names like vcard and vevent, which act as namespacing. In CSS it’s easy enough to quarantine microformat styles by also using the container class name. Now admittedly this means you can’t use those class names to mean something else inside a microformat where that class name has meaning. However microformats class names are generally meaningful, so wanting to use the same classname to mean different things is highly unlikely. Oli Studholme (talk) 14:33, 22 August 2010 (UTC)[reply]
The existing implementation of microformats is by-and-large confusing to the average editor
Unsubstantiated assertion. If you find things confusing, there is a project page where you can explain your confusion and seek help.
Many people have complained of this, including here and have been met with nothing but hostility from you. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
That is a lie. And still, no evidence to support the original assertion has been provided. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
I have complained, and you keep calling me a liar. OrangeDog (τ • ε) 23:34, 15 August 2010 (UTC)[reply]
You have what? I have never called you a liar; that is a lie. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:54, 15 August 2010 (UTC)[reply]
Thank you for the clarification. You have indeed complained. You are not "many people"; and your complaint does not validate the false statement quoted above. Furthermore, I can find no evidence of you seeking assistance for your apparent confusion, on the project-talk or any other page. What in particular do you find confusing? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:05, 16 August 2010 (UTC)[reply]
There are currently no user applications that make meaningful use of our microformats
False; see above.
Over-generalised; see previous. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Still false. Please see the view to which you are purportedly responding. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
Over-usage of metadata in all it's [sic] forms (COinS, etc.) actually makes the data less useful
Unsubstantiated opinion.
Unsubstantiated opinion. I gave quite sound reasoning as to why this is the case. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Cite? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
If you insist. Though if you're not bothering to read what others say, what's the point of participating in this discussion? OrangeDog (τ • ε) 17:29, 15 August 2010 (UTC)[reply]
You said "If we standardised on one type, user apps would be able to more easily deal with it. ". That, also, is a false assertion; it is certainly not "sound reasoning". To my great regret, I have read everything said, and cited, in this debate. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:40, 15 August 2010 (UTC)[reply]
Writing a parser for one metadata standard is almost by definition easier than writing a parser for two metadata standards. If you want an example of the other sort, would any tool be able to make sense of English Civil War if every date was wrapped with {{Start date}}? OrangeDog (τ • ε) 23:31, 15 August 2010 (UTC)[reply]
"writing a parser for two metadata standards". Another straw man. As has been shown, parsers for microformats exist already, and will continue to be written, regardless of what we do. {{Start date}} does not emit any microformats. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:54, 15 August 2010 (UTC)[reply]
Stop taking my arguments out of context. this is obviously a reply to this, and not a general argument against microformats. OrangeDog (τ • ε) 10:16, 16 August 2010 (UTC)[reply]
I have not taken your arguments out of context. Nor do I dispute that the former edit was made in reply to the latter; or that it is "not a general argument against microformats". It remains a straw-man argument. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:56, 16 August 2010 (UTC)[reply]
In some cases (e.g. {{Duration}}), existing style, flexibility and guidelines must be violated in order to correctly emit microformats.
False; see talk page. {{Duration}} renders content in exactly the same visual style as the plain text which it replaces...
False; see [2] as previously discussed. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Cited diff is not evidence of asserted claim, as previously discussed. Furthermore; as already explained, {{Duration}} renders content in exactly the same visual style as the plain text which it replaces: 4:32 vs. 4:32. Which one of those is plain text, and which uses the template? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:27, 16 August 2010 (UTC)[reply]
...is that the date the subject was active in their field, their birth date, or some other information?
This is usually determined (in Wikipedia) by the template parameter name; and in the emitted microformat by the class name (bday for birthdate, or the creation date of organisations and places; dtstart for start date, published for audio recordings, etc.) and context. (There is as yet no microformat attribute for "active in their field"). No example of this issue having caused confusion or ambiguity is provided.
The templates emit all of these, not distinguishing between them. No example is provided, as no example of the data being used can be found. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
The templates emit the HTML classes, but not as part of any metadata system. You have already been invited to put forward alternative templates. The rest of your reply is untrue. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
We should be looking for [microformats] which are ... in real use outside Wikipedia
All the microformats we use are in real use outside Wikipedia.
Yes, but for social networking sites, calendar management, etc. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Not only that. And even if true, so what? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
we should be looking for [microformats] which are ... not overly specific to particular entities, particularly non-free software
There are no microformats "specific to particular entities" or " specific to ... non-free software"
hCard specifies that it is for contact data, not generic information about people; hCalendar specifies that it is for a calendar event, not generic dates; hRecipe specifies that it is for a recipe, not generic foodstuff information. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Irrelevant to point under discussion; and untrue. But all our microformat implementations are in accord with the relevant specifications. For example, first line of hCard spec is "hCard is a simple, open, distributed format for representing people, companies, organizations, and places"; of hcalendar "hCalendar is a simple, open, distributed calendaring and events format". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:40, 15 August 2010 (UTC)[reply]
Microformats are .. basically a hack. This hack is messing with the 'default' lack of semantic meaning of the html/css
No, Microformats are using the semantic tool - class names - built into HTML in the way that was always intended. Read the HTML spec.
The way we are using them - emitting contact details for historical figures, calendar events for presidential terms - is a hack. OrangeDog (τ • ε) 15:59, 15 August 2010 (UTC)[reply]
Unsubstantiated and wrong. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:01, 15 August 2010 (UTC)[reply]
COinS, another semantic metadata format, is problematic in the gigantic overhead it creates for references, due to basically duplicating all the data.
Although COinS are outside the scope of this RfC, this comment highlights one of the advantages of microformats: they label the content on the page, there is no need to duplicate it, reducing volume and removing the possibility of disparity between data and metadata [item added 17 August]
Templates such as {{Start date}} do duplicate the data for use in microformats. OrangeDog (τ • ε) 09:51, 18 August 2010 (UTC)[reply]
That is the exception, not the rule. The date is repeated, hidden from view by CSS, in machine-readable format. This is to avoid the <ABBR> accessibility issue referred to (and complained about as being in use on Wikipedia when it is not) elsewhere in this RfC. This happens only for dates. This technique is so successful that it is being adopted as part of the HTML5 specification as the <TIME> element. If you have a better solution for making on-page dates machine readable as desired by the Wikimedia Foundation (see Wikipedia:Requests for comment/Microformats#Introduction), please propose it. There is no "gigantic overhead" in microformats. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:10, 18 August 2010 (UTC)[reply]
As long as people are following the MoS, then they already are. That's how AWB et al. parse dates; the possible formats are all known. I was just pointing out that you were making incorrect, unfounded and overgeneralised assertions. OrangeDog (τ • ε) 14:42, 18 August 2010 (UTC)[reply]
Having AWP attempt natural-language processing may make dates readable to AWB; it does not make them readable to devices outside Wikipedia in the manner desire by the Wikimedia Foundation. Microformats do. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:12, 18 August 2010 (UTC)[reply]

Response by Quiddity

[edit]

A few comments, based on observations over the last few years.

People: Yes, Andy often writes with a very blunt or aggressive manner, which many editors find frustrating. On the other hand, he does get asked the same questions repeatedly, which he must find frustrating. Everyone (everyone) could benefit from a lot more patience and friendliness in their writing with each other. (and for deity's sake, never ever use sarcasm here. it's an instant backfire, almost every time.)

Microformats: I believe much of this could be cleared up with a clearer FAQ, and set of examples, which is hopefully what this RFC will lead to.

Some of the repeated objections seem to ultimately stem from the titles of the microformats: hcalendar, hrecipe, etc. Again, this is hopefully resolvable just by running through a few examples. E.g. Caesar Salad currently emits metadata (via ADR and hRecipe microformats) that denote the origin of the dish (country and region) and a list of the primary ingredients. With this metadata in all our food-related articles, someone would be able to search for "all dishes that originate in Sicily and contain dill", for example.

Similarly with hCalendar, it's for generating things like timelines. We should be able to enter the url for List of ships attacked by Somali pirates into a site/program, and it will use our metadata to autogenerate a timeline of events, and in this case it could also generate something like a heatmap (as people are doing with the wikileaks info). E.g. a simple example via dbpedia, Aerosmith album timeline. I tried a few other sites, but I can't find many working examples; perhaps Andy can point towards some more?

I don't know much about microformats, but I greatly look forward to the time when our Category:Graphical timelines is huge and useful, by being able to add/overlay/zoom/etc into all the available data, on any given topic (from cars, to species, to people, to wars, to food).

So: With real-estate, the mantra is "location, location, location". With metadata at Wikipedia, the requested mantra is "examples, examples, examples (and documentation)".

Or something like that. :)

(Does this fit the RfC "View from" format? Should I move (some or all of) it to the projectpage, or leave it here for discussion?) -- Quiddity (talk) 22:07, 14 August 2010 (UTC)[reply]

Each microformat we use is listed and documented on (or via) the project page. Each template which emits a microformat links to they project page. It's clear from the views and endorsements made on the RfC that many people !voting to limit or remove microformats have either not read that documentation,or not understood it. I suggest you move (or copy) a revised version of your comments, minus the those directed at me personally to a view on the RfC. That doesn't preclude you from endorsing one or more other views, of course. There is an existing Timeline tool; used, for example, via the external links section of Bob Brettle. Unfortunately, it's temporarily broken; the author has promised a fix once he returns from his holiday. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:32, 14 August 2010 (UTC)[reply]
Done. Copied to Wikipedia:Requests for comment/Microformats#View by Quiddity. -- Quiddity (talk) 22:47, 14 August 2010 (UTC)[reply]

Point of order

[edit]

Why is Andy permitted to move clarifications from the project page to talk, yet his own replies to other's views may not be likewise moved. He has also re-factored some of my replies resulting in loss of context. OrangeDog (τ • ε) 17:26, 15 August 2010 (UTC)[reply]

Please read the instructions at the foot of the Project page. Nothing you wrote has been refactored (apart from the insertion of missing sigs - please feel free to remove these if you feel that is helpful). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits
You have removed what "Classes are not 'defined by an extension'" was in reply to, rendering my further comment meaningless. Your "Concerns" section is clearly discussion and replies to others' views, whereas Xeno's TheDJ's clarifications that you moved are much less so. OrangeDog (τ • ε) 21:54, 15 August 2010 (UTC)[reply]
Yeah his concerns section should be on the talk page, its clearly discussion. -DJSasso (talk) 22:16, 15 August 2010 (UTC)[reply]
I don't believe it would be helpful to this process, to move his "Concerns" section from his "View" to here. It's currently a set of clearly written explanatory details. If the whole section were moved here, he'd just have to rewrite it again, without using quoted remarks as the starting point for each explanation.
E.g. he'd just refer to the html5.0 spec for class, without giving the context that people above are misunderstanding it: "There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content."
I'm not sure what content by Xeno anyone has changed. Is this a significant problem, or more of an etiquette quibble? -- Quiddity (talk) 23:12, 15 August 2010 (UTC)[reply]
[3] [4] OrangeDog (τ • ε) 23:20, 15 August 2010 (UTC)[reply]
Neither of those edits seem related to Xeno. Possibly you meant to specify The DJ?
The DJ's comment could easily be copied back, if you feel that would be helpful to the RfC, leaving the copy above with Andy's reply attached.
The second diff, where your comments have been edited (before, after, and current state of that section) seems essentially harmless (though admittedly poor etiquette), and I see no problem with the restoration that you have made.
So, is there actually a real problem, or can we get back to discussing microformats? -- Quiddity (talk) 00:23, 16 August 2010 (UTC)[reply]
I didn't edit any of OrangeDog's comments; I removed the redundant quoting which had been moved from my view in the RfC. The former edit was the first half of a move from the Project page to the discussion page, of post-view discussion, as dictated at the foot of the former. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:33, 16 August 2010 (UTC)[reply]

It's mostly just very annoying and poor etiquette. OrangeDog (τ • ε) 10:09, 16 August 2010 (UTC)[reply]

I agree that your removal of an entire section of my view from the RfC Project page was "poor etiquette". But I forgive you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:00, 16 August 2010 (UTC)[reply]

Response to Thumperward (Chris Cunningham)

[edit]

Chris says:

our deployment … can actually be harmful … one of the triggers for this RfC was the deployment of microformats to mark up stub templates, and I think it's odd that nobody has linked to that discussion yet: see template talk:asbox#Add 'bodyclass' parameter, redux and the associated archive page. In that case, there were apparently legitimate concerns that the proposed class addition wasn't productive.

The concerns expressed were refuted, and thus not (or least least no longer) legitimate; and no potential for harm was ever demonstrated. The proposal was to facilitate the use of HTML class attribute mark-up in stub templates in a better way than is already used, thereby reducing complexity and facilitating ease of editing. The same people who blocked this simple edit request are also arguing in this RfC to reduce complexity and increase ease of editing! The use of microformats in stubs also accords fully with both HTML and microformat specifications. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:15, 16 August 2010 (UTC)[reply]

Accessibility discussion elsewhere

[edit]

I'm surprised that OrangeDog has neglected to mention this exchange, from a few hours ago:

  • I was wondering if microformats had any effect on the operation of a screen reader, or whether there are any other accessibility issues. [OrangeDog]
    • No, they don't affect the output of screen readers. [Graham87]

As some of you may know, Graham is a screen-reader user and is heavily involved in improving the accessibility of Wikipedia. As I've already stated, our implementation of microformats takes great care not to harm the accessibility of Wikipedia. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:34, 16 August 2010 (UTC)[reply]

Screen readers are not the only accessability concern. -DJSasso (talk) 11:46, 16 August 2010 (UTC)[reply]
Did anyone say there were? Graham was also asked about "other accessibility issues" and has not reported any. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:58, 16 August 2010 (UTC)[reply]
You implied it as though it were. -DJSasso (talk) 12:09, 16 August 2010 (UTC)[reply]

I've been at work and thus not able to use Wikipedia for very long. Good thing you were stalking me him though, or no-one would have found out that there is nothing to add to the discussion. OrangeDog (τ • ε) 17:53, 16 August 2010 (UTC)[reply]

Because of our shared interest in accessibility, I watch Graham's talk page. So that's another unfounded false allegation from you, impugning me and irrelevant to the RfC. You edited here between Graham making his comment and me starting this section. This adds a great deal to the discussion; it further refutes the false allegations that have been made about the accessibility of our microformat. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:29, 16 August 2010 (UTC)[reply]
Nobody made any allegations that microformats harmed screen-reader accessibility, and I'm not going to as I checked first. Yes I edited briefly while at work today, but I had lots of work to do, so I stopped. OrangeDog (τ • ε) 19:57, 16 August 2010 (UTC)[reply]
Yes, they did. Do keep up. Your repeated allegation (in edit summary) of stalking is unacceptable. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:20, 16 August 2010 (UTC)[reply]
Show me the diff where someone mentioned screen readers during this RfC. OrangeDog (τ • ε) 22:29, 16 August 2010 (UTC)[reply]
Here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:55, 16 August 2010 (UTC)[reply]
OK, I was looking for a more specific concern than that. But as you said, that point was already resolved, so there's no need to bring it up again. OrangeDog (τ • ε) 10:21, 17 August 2010 (UTC)[reply]
Graham87 is able to test with a screen reader. Which is already a lot, and he is a big help. But note that he is not able to thoroughly review accessibility for WCAG 2.0 conformance. At any rate he is right: those Microformats are made of span elements which doesn't have any semantic value (it's made for layout purposes). Theses spans doesn't contain any content, only the class is used. There won't be any problems with that.
We have a lot of bad uses of span on Wikipedia though. For example, in {{Navbar}} <span title="edit this template">e</span> is not accessible and will not be read by assistive technologies. It should be replaced by <abbr title="edit this template">e</abbr>. But theses bad uses of spans doesn't concern Microformats.
Oh, but now that I see the examples given in hCalendar I can tell the accessibility concerns are correct if ABBR is misused like that. I only saw SPANs being used for Microformats so far which is fine. But if ABBR were to be used that way it would create accessibility concerns for sure. Yours, Dodoïste (talk) 22:44, 16 August 2010 (UTC)[reply]
It's not used like that on Wikipedia. This has already been explained, above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:21, 17 August 2010 (UTC)[reply]
Fine then. :-) Dodoïste (talk) 17:35, 17 August 2010 (UTC)[reply]

More focussed discussion

[edit]

I thought it would be more useful to look at different formats/templates separately, to avoid lengthy tangential threads. The idea in this section is to keep things brief, and we can look in more detail later. Feel free to add more headings. OrangeDog (τ • ε) 11:13, 17 August 2010 (UTC)[reply]

Discussion is helpful. !votes are not - there's a RFC for this. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:55, 17 August 2010 (UTC)[reply]

Coords

[edit]

{{coord}}

hCard

[edit]

hCard

  • Undecided. Appears designed primarily for providing contact details, which is outside of project scope. OrangeDog (τ • ε) 11:13, 17 August 2010 (UTC)[reply]
    • You write this below a reply to you personally, which states: "first line of hCard spec is "hCard is a simple, open, distributed format for representing people, companies, organizations, and places"". Providing contact details in the form of official URLs and locations in Infoboxes, is not "outside of project scope". hCard is emitted by {{Coord}}, which you support, above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:47, 17 August 2010 (UTC)[reply]
      • Yes, which clearly means their contact details. -DJSasso (talk) 12:07, 17 August 2010 (UTC)[reply]
        • Not at all. There is nothing in the spec which says that it is to be used only for contact details. Providing contact details in the form of names, official URLs and locations in Infoboxes, is not "outside of project scope"; it is done widely. hCard is emitted by {{Coord}}, which OrangeDog supports, above. Other organisations reuse the details we emit in hCard. The examples given in the hCard specification (some of which, for example, have only a name, or only a name/ URL pair) support the way we use hCard. You are (both) rehashing points which have already been addressed in this RfC. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:10, 17 August 2010 (UTC)[reply]

Marking it up semantically and altering how it visually appears on our pages so that other third parties can use it to create directories is pretty much the same thing as us creating the directory, ie we are harming our product to help someone else create a directory. Cutting and pasting is completely different in that we don't have to alter our layouts, introduce possible issues, make things harder to use etc etc.-DJSasso (talk) 13:20, 17 August 2010 (UTC)[reply]

Microformat mark-up does not "alter how it visually appears on our pages". If you truly believe that what we do is "pretty much the same thing as us creating the directory" then there's no point in discussing this with you further; but I do have a bridge you may be interested in buying. No harm has been demonstrated. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:23, 17 August 2010 (UTC)[reply]
Do I need to point you back to the examples of you asking to have various infoboxes visually changed so that your microformats will work in the way you want them to? There have been a few instances pointed to on this page already, and I can point to alot more. So yes, up to this point they have altered how our pages work. Harm has been demonstrated to you numerous times by numerous people, you just keep dismissing it. -DJSasso (talk) 13:29, 17 August 2010 (UTC)[reply]
They are not "my" microformats. I have suggested various ways in which templates can be improved for several years; sometimes to also allow better use of microformats, sometimes nothing to do with them. We have never been forced to make articles look worse in order to emit microformats. Can you provide an example where removing microformat mark-up, alone, will make a template look better? No evidence of harm has been demonstrated; some incorrect allegations of harm have been made - and refuted. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:38, 17 August 2010 (UTC)[reply]
You disagreeing is not a refutation. OrangeDog (τ • ε) 17:49, 17 August 2010 (UTC)[reply]
For once you are absolutely correct. That's why I posted a refutation, and not simply a statement of disagreement. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:52, 17 August 2010 (UTC)[reply]

hCalendar

[edit]

hCalendar

hProduct

[edit]

hProduct

hRecipe

[edit]

hRecipe

hAudio

[edit]

Start date

[edit]

Duration

[edit]

{{duration}}

COinS in cite

[edit]

{{cite}} et al.

Response to OrangeDog

[edit]

Regarding this revision of your view: some of the functionality of {{Coord}} can be obtained via the toolserver, without using the embedded microformat, but other facilities; and interoperability with other parsing tools and sites, are only available using the microformat, as described above. If you are not willing to concede this, please provide a demonstration of such functionality occurring, without using microformats. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:04, 17 August 2010 (UTC)[reply]

Well obviously a microformat parsing site will only work if there are microformats there. However, I can still draw points on a Google Map by using geohack. OrangeDog (τ • ε) 17:46, 17 August 2010 (UTC)[reply]
I didn't ask you to use a microformat parsing site; I asked you to demonstrate functionality, not method. Can you? Can you show us the RDf or JSON output? You failed to do when I asked you the same thing, above, on 11 August: twice. Can you do the same for non-coordinate data in hCard, hCalendar and our other microformats? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:24, 18 August 2010 (UTC)[reply]
Having RdF- or JSON-format data is not application functionality, having points drawn on a map is. I'm only interested in end-user benefit. OrangeDog (τ • ε) 14:44, 18 August 2010 (UTC)[reply]
So, in conclusion, {{Coord}} without microformats cannot provide all the functionality and benefits of {{Coord}} with microformats. I'm glad you've now got that clear. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:07, 18 August 2010 (UTC)[reply]

Response to Xeno’s original RfC statement (by Oli)

[edit]

I’m not sure if Xeno has changed opinion on any of the points originally made, so I’d like to address them;

  • as-yet-unproven technology — I’m not sure what you mean by this. Microformats are widely deployed, and used by third parties, for example in Google Search. What would make them a proven technology for you?
  • little-to-no benefit to the average Wikipedia reader — This is a valid argument for direct reader interaction with microformats. However readers benefit from third-party uses, such as more informative search results.
  • unnecessarily complicating templates — the cited Duration template doesn’t seem like a good example to use. It is only a small part of the templates it’s used in. It’s well documented, and the extra metadata it adds also acts as code commenting to increase meaning. I imagine without it you’d need guidance to prevent the occasional addition of minutes-only values (like films), specify if zero units are required etc. Is “|h=” etc (vs “:”) really such a big deal if it’s already in the template? It’s two extra characters — not such a great example of complexity increase. Wiki templates and syntax are already crazy complicated, so this doesn’t seem like a significant example of the problem you describe.
  • “yummy hack fodder” — I don’t see how one Yahoo employee’s opinion is that significant, and I’m guessing this is quoted out of context (or this doesn’t mean what you think it means). Alternatively, we could have a quote-off ;-) Microformats “help people make more informed clicks and find what they need even faster” — a Google employee :D
  • I agree with the last part of your comment, but for me extra semantic information (as long as it’s not too onerous) seems like a good thing, much in the same way adding good alt text to images is. Even if only one user (Google) gets some benefit, all readers do. The big questions are what semantic information and how onerous. For me microformats seem like good semantic information to encode (there’s a limited number of them for specific and common data types), and they also seem as easy as anything else in Wiki templates. Do you still perceive them as unnecessary and overly complex?

Responses to some other perceived disadvantages

[edit]
  • lots of class names — perfectly fine in HTML, and a general trend (ref: OOCSS)
  • class names being reserved — microformat classes are only relevant inside a container class with a funny name (like vcard), and this acts as namespacing
  • microformats are heavy and slow to download — relative to the whole, nope. HTTP requests are far more time-consuming than actually sending content, HTML compresses really well, and hey microformats are a small fraction of any page’s HTML. You’d remove far more by moving inline styles into stylesheets.

Other comments

[edit]

Xeno, I think your original RfC comments were somewhat loaded, and it’s understandable that anyone heavily invested in microformats would find them confrontational. I personally had a “huh?” reaction to several points, and I haven’t added a single microformat to Wikipedia. Please consider this in regards to Andy’s responses. I don’t think this changes the fact that Andy would get a far more balanced hearing if he cut the debating club captain persona. You’re doing things the hard way yo.

Peace - Oli Studholme (talk) 15:10, 22 August 2010 (UTC)[reply]

Thanks for your comments. To answer your question as to whether my opinion has changed, I am still soaking in the responses and waiting to see what others think. As far as being somewhat loaded - I don't (didn't) know much about microformats - I had originally asked Andy to prepare this RfC since he is the resident expert. Unfortunately he declined, so I had to do what I could with what bits and pieces of information I had. For what it's worth, I'm not entirely opposed to them if they have demonstrable use (and Jack's comments on "enabling the future" are noted as well): my main goal was to get some kind of community-stamped directive on these things such that (if they are desirable,) they can be integrated in a non-disruptive and organized fashion. –xenotalk 00:02, 26 August 2010 (UTC)[reply]
Thanks for your reply Xeno. Regarding the specific points I raised in my comment above, are there any that you’d like to discuss in more detail or reply to, or is there other information you’d like (apart from more opinions from other Wikipedians) to solidify your position? Also, for future reference, I think your original comment would have got more helpful responses by asking questions, such as “are microformats well-adopted?” or “what benefit do they give to Wikipedia users?”. Your comments certainly give the impression you knew enough about microformats to decide they were as-yet-unproven technology with little-to-no benefit (both points I would disagree with). I’d like to add something to the RfC, but until I have more information about what you are still concerned about it’s hard to do so. I’d really appreciate further dialog to clarify this; for example do you see demonstrable use in the examples already given, and do the template-related replies satisfy your concerns about integration? TIA Oli Studholme (talk) 02:16, 30 August 2010 (UTC)[reply]
I still haven't seen a good on-wiki use for microformats, so they're unproven in terms of direct utility to the Wikipedia readers. But I suppose that's kindof the point, that the metadata is for external tools, some of which show promise. I still think that if microformats are to be deployed globally, a consistent, organized, and consensus-based approach (with grounding in a detailed guideline) would be desirable versus the way microformats are being deployed at present and that was one of the main motivations for putting forth this RFC as explained in the desired outcome. Do note that microformat proponents have been asked on several occasions to initiate this process. Please proceed with adding your view/examples... –xenotalk 15:41, 1 September 2010 (UTC)[reply]

Formatting of RFCs

[edit]

Just a note to explain my change:

The centralized lists of RFCs are less readable when we get long descriptions and the first response or two. Also, the resulting bot-generated link takes respondents directly to the section that the RFC tag is in, which means that if the RFC tag is under ==Desired outcome==, they'll miss all the background, links to previous discussions, etc. that is above that section heading.

Any editor who wants to provide a better "question" for the centralized pages should feel free to improve what I've done. WhatamIdoing (talk) 18:47, 25 August 2010 (UTC)[reply]

I changed your wording to "Should Wikipedia continue to use microformat markup in templates? " to more accurately reflect the issue at hand. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:04, 25 August 2010 (UTC)[reply]


What should we do?

[edit]

Much as I hate even virtual paperwork, I rather think that what we need is a concrete proposal hammered out by some of the extremely clever and knowledgeable people involved in this discussion. I would propose that it should address main points:

  1. A simple system for including metadata - as transparent to editors as possible: Example: using the time functions it is possible to emit metadata for a date passed as a free-form string, rather than forcing the use of a nested template.
  2. A flexible taxonomy of data types and relations, and an indication of how this could be refined in the future.
  3. A system for turning on or off metadata of appropriate types as required (i.e. COins/uformat/others) as and when they are useful or not.
  4. A list of benefits that actually accrue to the project.

Taking a step back it may make more sense to have a MediaWiki feature, a template set, a CSS class, or some other technology to implement this, if we decide it's a good idea. It may also fit in with other things, such as semantic wiki, or database extensions. It may work better as a feed, where you can pick up the metadata without the data (I'd rather download 110 bytes to my app than 1.8 M).

Rich Farmbrough, 23:44, 25 August 2010 (UTC).[reply]

There is no instance where microformats (the subject of this RfC) cause anyone to "download 1.8 M [bytes]". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:29, 26 August 2010 (UTC)[reply]
By your own admission[6], microformat class names can impact page size quite considerably. OrangeDog (τ • ε) 17:55, 29 August 2010 (UTC)[reply]
While this is potentially true for a page where the content is limited to only to microformatted content, or doesn’t contain much non-microformatted content, I don’t think this is relevant to Wikipedia. An additional 461 bytes (as per the example on Andy’s talk page) is inconsequential. For comparison that would be ~1% of this page’s HTML weight, or ~0.25% of this page’s total weight. If you are concerned about performance, I’d suggest starting with low-hanging fruit; reducing HTTP requests (JS/CSS), removing inline styles, and optimising images, as you’ll get far bigger gains out of them. Finally, @Andy, I’m pretty sure Rich is referring to the metadata being only 110 bytes vs an entire page at 1.8 MB (i.e. the 1.8 MB has nothing to do with the addition of metadata). Oli Studholme (talk) 02:38, 30 August 2010 (UTC)[reply]
Oli is correct, I mean exactly that. He's also right about about low-hanging fruit. The only thing he's wrong about is 0.25% being inconsequential - .25% of the UK tax take would make me very rich - and taking the ratio with large pages only, total meta-data on person stubs is a very high ratio, and on the wiki-source of redirects probably over 50%. Rich Farmbrough, 18:20, 13 September 2010 (UTC).[reply]

d we do? I'd suggest a first priority would be obtaining input/feedback from Erik Möller, for him to clarify the technical & WMF positions on these issues, and offer advice, etc. That would be relevant and important information to have.

I'm not sure whether a list of specific questions should be prepared, or if he should just be given another context-less invite to this page. (He's probably a busy chap, and this is a long RfC, so I'd hope the former option, or something better...). HTH. -- Quiddity (talk) 19:25, 29 August 2010 (UTC)[reply]

Template:Birth date

[edit]

I'll get promptly corrected if I get this wrong, but it looks to me as if we have at least one (often used) template that used to work perfectly for all dates, but because of the introduction of microformats, now only should be used for dates after 1583 CE: Template:Birth date. Obviously, as indicated by examples like Mikołaj Rej, many editors are not aware of such restrictions (or the template was already used before the restriction was placed). This gives us pages like Wikipedia:WikiProject Microformats/dates, with sentences like "Any editor encountering such usage should change the date to plain text with no date template; or if not confident in doing so, raise the matter on the relevant talk page." Basically, because of microformats, some editors want us to change things that used to work perfectly allright to another format, since microformats aren't capable of handling the current use correctly. No, thank you... If it is true that "Therefore, use of such templates for non-Gregorian dates or dates outside that range constitutes a false claim of conformance to the ISO 8601 standard.", then get rid of the microformatting and just keep the template. Fram (talk) 14:34, 3 September 2010 (UTC)[reply]

A question

[edit]

I'm undecided on this issue -- to give the short version. But my primary concern about this matter is this: if the English Wikipedia community is undecided -- or even opposed -- to the idea of microformats, will the Foundation force us to adopt them, like it or not? I would hope this would not be the case, even if the community is seriously wrong about the matter. -- llywrch (talk) 02:16, 8 September 2010 (UTC)[reply]

I don't believe the Foundation has taken (or is likely to take) any position on such a fairly trivial issue. --Cybercobra (talk) 04:56, 8 September 2010 (UTC)[reply]

Closure

[edit]

This has now run for over a month, the RfC tag has expired and discussion seems to have petered out. Is anyone opposed to asking an uninvolved admin to close and summarise the consensus so we can move on? OrangeDog (τ • ε) 12:01, 10 September 2010 (UTC)[reply]

I do believe it is necessary to obtain feedback from Erik Möller. The first paragraph of Andy's view makes it sound like this could be key information of have.
Would you (or someone) be able to summarize the core issues/questions that need to be resolved? So that we can ask him about some specific items, rather than asking him to wade through all the views and discussions... Or possibly that is what the uninvolved admin might be asked to do? -- Quiddity (talk) 18:47, 10 September 2010 (UTC)[reply]
I have provided a close. I think there was a clear consensus to move forward with care on microformats, and to provide some form of documentation/advice/guideline/principles. Even those who were least in favour of using microformats were not calling for a ban, but for discussion and guidance on their use. There was only one comment in support of microformats which did not at the same time articulate some view that it would be advisable to implement some care in their deployment. I think it would be appropriate now to move forward with a discussion on what format of care would be most useful. Should it be a simple guideline, or should it be a microformat request for approval? SilkTork *YES! 19:14, 10 September 2010 (UTC)[reply]

Guideline drafting

[edit]

I have created Wikipedia:Microformat guidelines and its talk page for further discussion. OrangeDog (τ • ε) 20:30, 13 September 2010 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_comment/Microformats&oldid=1241357557"