Re: [uf-discuss] hCard and Internet Retailers (Shopping Contact Information)
Hi Junaid, On 17 Oct 2010, at 10:19, Junaid Nazir wrote: However, before going forward with such an idea, we would need to know if there are any suitable classes to differentiate between different telephone numbers and email addresses (sales, customer service, technical, head office, switchboard/operator) These are ‘agents’. You'd have a main vcard for the company (span class=fn org) which along with the main contact (head office or switchboard perhaps?) then contains any number of div class='vcard agent' children, each of which is another hCard, representing a different part of the company (organization-unit, or a person.) Since each agent is an hCard too, they can have phone numbers, addresses of their own. and further how to list multiple addresses for a company (head office address, local chain store differentiated by zip/post code) Chain stores I think you should just represent as standalone, separate hCards. An hCard is a representation of a business card (and can be quite substantive, especially with agents) but it is not a model of an entire _business_. Different hCard for difference branches is fine. and if there is scope to include 'store opening times' and for e-commerce sites: if they have a 'reserve collect' service (where you can order online, but collect in store without having to wait for a delivery). Opening times could, with some a bit of improvisation, be represented using hCalendar. Recurring events from vcalendar haven't really been deployed on the web as yet, so the actual presentation would need some exploration, but hCal is the way to go. Any specifics of a Reserve and Collect service is out of scope of hCard, but if it's just a particular URL or a particular phone number, you could again represent it with an hCard as an organization unit of the company. Hope that helps, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hProduct/hReview issue
On 16 Apr 2010, at 05:49, Toby Inkster wrote: On Fri, 2010-04-16 at 12:57 +0100, George Brocklehurst wrote: There is an issue with using hProduct and hReview together: An hProduct can include one or more hReviews. Each hReview requires an item, which should be the hProduct. The include-pattern prohibits references to an ancestor. Therefore it is not clear how to include a valid hReview in an hProduct. The other possibility would be to relax the requirement for hReview to contain an item when it's obvious from context; the context in this case being that the hReview is within an hProduct. There is a similar concern re hProduct and hListing IIRC. This ties closely to some work I started documenting last year on “containers” in general. That being, the pattern where you have a number of microformats in a page applied to the same ‘item’, or more generally, where properties of the main subject of a page are shared by multiple microformat objects (such as, a TV listings page contains many `vevents`, they all share the same `location` (the channel name).) Could be worth adding to that documentation the `hProduct contains hReviews` pattern with that. As ever, further thoughts on the modelling are appreciated. http://microformats.org/wiki/container-brainstorming Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Help with proper method for incorporating/extending hRecipe
On 17 Mar 2010, at 14:50, thomas lörtsch wrote: can you document your additions on the wiki, maybe on the recipe-brainstorming page? Should be interesting to follow your process. Seconded. recipe-brainstorming is absolutely the correct place for this. Thanks! B.t.w.: POSH turned out to not be the right way to go? I think that this form of ‘extension’—where you use hRecipe as far as it will take you and mark up additional common elements with your own classnames *is* POSH. Documenting these new classnames and use cases for future recipe iterations is the best thing to do. The additional point I would make to Dave is to please try and document this work openly, as you go along (on the aforementioned -brainstorm wiki). That way you'll be benefit from Microformats process in your own work, and where desirable hRecipe additions do emerge, they'll can be drafted in tandem with your work and hopefully ease future compatibility between our work. Thanks, and good luck, Ben Am 17.03.2010 um 21:37 schrieb Dave Corboy: On Fri, Mar 12, 2010 at 11:28, Stephen Paul Weber singpolyma at singpolyma.net wrote: If there exists a vocabulary for your data, use it. Otherwise, you can add new terms... you should basically never invent something completely new and incompatible. Excellent. I very much appreciate the willingness of this community to provide guidance. This note suggests that it is appropriate to simply add properties to an existing microformat if they do not exist already. I could find very little information on extending microformats so I have been reluctant to do this without better guidance. Given this response I will proceed forward with adding our own extensions to hRecipe and continue to monitor this board in case there are additional comments. Best, Dave Corboy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Concerning the Technorati pipes
I've been fielding this question quite a lot over the past few days, since the recent Technorati.com redesign appears to have killed the landing pages for their contacts and events microformat pipes. I've heard from a number of people that they rely on the service and are concerned about it. I don't know what Technorati's plan is for the service, whether they are going to remove it, stop supporting it or whether the missing landing pages are just a configuration error. What is known is this: 1. The actual pipes themselves are still live and operational: * http://feeds.technorati.com/contacts/http://microformats.org * http://feeds.technorati.com/events/http://microformats.org/wiki/events Those URLs return 404s if you don't include the target URL. 2. For those concerned or with a reliance on Technorati's service: The Technorati pipes run Brian Suda's awesome, free and open source X2V transformer. As well as it running hosted on his personal site (http://suda.co.uk/projects/x2v , not recommended for production use—it's a little unfair to use Brian's personal site as a service) but you can also SELF-HOST the code as part of your own set-up, without any changes to your applications. There are also other transformers (Optimus, for example). So, I hope that provides a little info for people who might be concerned. If anyone from Technorati or who has a contact at Technorati could get actual clarity on the fate of the service that would be great, but the most important thing is that the code is open, and I hope the information in this email helps people out in maintaining their applications. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Problem with using class tel
Hi Volvox, On 27 Sep 2009, at 14:20, Volvox wrote: span class=telspan class=typeCell/span (061) 99 99 99/div But what if i dont want Cell word, and i would like diffrent? Do i really have to hide this 'type' span and make another before 'tel' with my text? span class=numerkom/spanspan class=telspan class=typeCell/span999 999 999/div Or maybe anyone got better ideas? Two options: 1. You do not have to include the type at all. You can just do: span class='tel'span class='value'(061) 99 99 99/span/span I feel that it is, at that this point in history, increasingly irrelevant whether a telephone number is a mobile telephone or a landline. The work and fax indications are more relevant, perhaps. 2. You can embed the type using the value-class-pattern http://microformats.org/wiki/value-class-pattern Like so: span class='tel' span class='type'span class='value-title' title='cell'/ span/span span class='value'(061) 99 99 99/span /span Telephone type is one of the properties for which this pattern is valid. Why in telephones there is mandatory text in object with class 'type'? It's not mandatory. The structure is inherited from vcard's property semantics in combination with the microformats principal of visible data. However, I agree that this particular detail was a massive internationalisation oversight to require en-us strings in page content. Requiring language specific visible content should be regarded as an anti-pattern for all future microformats developments. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] MySpace and Microformats
On 22 Sep 2009, at 17:47, Scott Reynen wrote: On Sep 22, 2009, at 5:56 PM, Karsten Januszewski wrote: I was just on MySpace and noticed that /some/ profile pages are now formatted using hCard - for example: http://www.myspace.com/ irhetoric. It appears that newly created MySpace profile pages are using Microformats now. However, lots of other profile pages don't use Microformats -- I'm guessing they are generated using a different codebase. I just posted a thread on the forums (http://developer.myspace.com/Community/forums/p/9026/43520.aspx ) to see what folks say, but I couldn't find any mention of it in the press, etc. Nonetheless -- another big win for Microformats adoption! Nice. I've done a lot of scraping of MySpace. In my experience, they roll out changes *very* gradually, over the course of weeks, if not months. So hopefully the microformat markup is part of the new version and will be everywhere relatively soon. MySpace has a branched codebase for profiles, the newer versions simply referred to as ‘Profiles 2.0’. 2.0 has been live for a while now, and upgrading from an old form profile to a new 2.0 form is actually in control of the MySpace user, not MySpace as a service. The reason for this being that the MySpace community is heavily based around profile visual customizations, all of which depend on the old mark-up. If MySpace ever upgraded all users to the new profiles there'd be outrage because people would lose their page designs. The number of third party templates for Profiles 2.0 is smaller than Profiles 1.0. So again, the incentive to switch is taking time to build up. That Microformats are there in the new template though is great news! B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: [uf-new] Using external Data with Flash
Hi Konrad, Thanks for getting interested in microformats! First up, query and discussion threads should be directed to the microformats-discuss@microformats.org mailing list, please; [microformats-new] is focused on the actual development of new formats, so your question won't necessarily have reached the right audience here. Thanks! I'm crossposting this over to microformats-discuss for you, so any future replies should please drop µf-new from the reply header. Thanks! On 27 Jun 2009, at 17:08, Konrad Röpke wrote: I want to program a possibility to access an external file online on a server with a Flashfile. Would that be possible also with an hCalender file? Thanks for any help or recommendations. Could you clarify a little what you want to do? If you're trying to parse hCalendar within a Flash application, you might be able to reuse some of the JavaScript code from the Operator parser to create JavaScript objects. See http://microformats.org/wiki/operator Cheers, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mixing vocabularies
On 26 Jun 2009, at 21:33, Peter Mika wrote: So even if we all agree to all this, minimally two changes needed to the example on the wiki: -- hcard should be vcard -- all required properties of the hcard should be present OR hcard should be removed Would you edit it? Noting that Tantek has edited the hCard class out on the wiki. I think we should assume that this was an error in the draft (note that hRecipe is draft). **I think** I understand what has happened here. Thomas, if this assumption isn't correct I apologise. However, I hope this explanation is valuable anyway in the context of this ‘combining vocabularies’ discussion, so please consider the following neutrally: This discussion started from a mistaken understanding about combining vocabularies in microformats — e.g. combining hcard with hreview to reuse terms like `fn`. combining is a concept applied from a formal vocabulary context, where you would import two vocabulary namespaces into different prefixes to reuse terms. (e.g. importing dublin core and atom namespaces and using them in combination as part of some larger document mark-up). In XML, reusing vocabulary terms requires a formal reference, because when you use `dc:title` you're using _the same_ `dc:title` as in every other use of Dublin Core. In XML, this combining of vocabularies is a publishing-time operation. In microformats, that concept doesn't exist. The sharing of terms between vocabularies is a simpler **design-time** decision. Where terms a new format has fields that share the same use with a term defined from a previous microformat, the term is re-used in the new vocabulary. So, in hRecipe, `fn`, `type`, `value` and `photo` are not ‘imported’ from hcard, they are simply properties with the same name, because they are used the same way. The hRecipe spec currently emphasises where terms have been reused from hCard (this is good, it clearly documents the design decisions of the draft). And, in the case of ingredient, it documents that `type` and `value` are reused from hcard (that's correct). I think the example was using class=ingredient hcard with the intent of explicitly referencing the hCard vocabulary for `type` and `value`. However, that isn't necessary. `type` and `value`, are first-class members the hRecipe draft vocabulary, and the context of their use is indicated by the root class name `hrecipe`. This is why I explain microformats as objects: `class=hrecipe` means this is a recipe object not import the recipe vocabulary. I suspect this is the muddle that happened with the example, but even if not, I hope this explanation makes things a little clearer for those who switch between the different vocabulary models on the web. Cheers, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mixing vocabularies
On 24 Jun 2009, at 23:02, Dan Brickley wrote: So, in this case the vevent in that page — http://www.answers.com/topic/kevin-bacon — is invalid — certainly incomplete. That structure doesn't contain any dates at all. Does a validator exist that can detect this? If not, could one be built? Yes. Optimus flags the error: http://microformatique.com/optimus/?format=validateuri=http://www.answers.com/topic/kevin-bacon I'll start up a brainstorming page for that though; we talked about it with the other SearchMonkey guys at the µf dinner a few weeks ago. great :) I've started a new brainstorming page at http://microformats.org/wiki/representative-object-brainstorming to collect any and all thoughts on how you might prioritise one object over another in a page. Everyone is encouraged to add their thoughts and any techniques they have. I've referenced the representative-hcard page there. Cheers, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mixing vocabularies
Hi Peter, On 24 Jun 2009, at 18:55, Peter Mika wrote: Look at for example at [1]. This page contains the following markup: table class=infobox infobox vcard vevent cellspacing=5 style=width: 22em; text-align: left; font-size: 88%; line-height: 1.5em; font-size:90%; text-align:left; tr td colspan=2 class=fn summary style=text-align:center; font- size: 125%; font-weight: bold; font-size:110%; background:khaki;Kevin Bacon/td /tr If I look at it strictly, I have a vcard and an event object which both have the name Kevin Bacon. However, what the author intended is probably a person object, with some terms borrowed from vevent (not sure which ones). So, in this case the vevent in that page — http://www.answers.com/topic/kevin-bacon — is invalid — certainly incomplete. That structure doesn't contain any dates at all. What I posit has happened is that at one point, answers.com marked up the ‘Years Active’ part of that info box with dtstart and dtend. They're not marking up one object with a combined vocabulary, they're marking up two objects: One card (for Kevin Bacon) and one event (Kevin Bacon's Career). I think they backed out dates at some point, but have left the root class and summary class in place. With the dates in place, two distinct but valid objects would be parsed out. Answers.com could instruct someone on how to parse the two microformats in combination for additional context, but the structures standalone too. So what do you guys think about this? Note that on our side this introduces the secondary problem that we now have to figure which object is the main topic of the page (it's very clear for the human!) Figuring out ‘the microformat for the page’ is not a consequence of ‘mixing vocabularies’ in this context; that is, overlapping or integrated structures. It's a problem presented when you have multiple objects (of any structured data origin) anywhere in the same page. That's a really interesting problem in itself, but not directly correlated with this one. I'll start up a brainstorming page for that though; we talked about it with the other SearchMonkey guys at the µf dinner a few weeks ago. Cheers, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and keyword spamming
Hi Elli, On 2 Jun 2009, at 00:01, Elli Albek wrote: 1. Non semantic HTML. The pages include a lot of repeating terms in the wrong places. There is no way to avoid it if we want to use hreview. Repeated content is of course undesirable, but please don't conflate it with being “non semantic”. 2. The pages become less accessible, since the HTML starts deviating from its semantic form. For example, include pattern requires: The include pattern offers you choices to reference other content in the page. It's not perfect, I agree. I would appreciate some clarity on your problems below, though: a. object tags (this should ALWAYS be avoided at all cost!!!) We are aware of and have documented scenarios where `object` is problematic, but that doesn't equate to ‘ALWAYS be avoided at all cost’. If you have a new case with the `object` version is as horrific as you make out, please document it on http://microformats.org/wiki/include-pattern-issues . If not, please keep your descriptions concise and free from overreaction, as it confuses attempts to assist you. b. empty A tags These are pretty much outlawed by the spec now, based on previous accessibility research, C. A tags with redundant information that is constantly repeating on the page. This is what we currently do as the lesser of all evils. This is a compromise, of course. Is it really evil though? Suboptimal, sure, but evil? You'd be repeating the name of the restaurant somewhere. It can be fit into the structure cleanly, and it can be hidden if you want. h2 class='summary'a class='include' href='#item'The Alembic:/a Great food and cocktails!/h2 p… etc./p Yes, not perfect. But can be designed in cleanly. 3. Needing to repeat so much text on the page affects search engine results: Repeating terms that are almost irrelevant to the page, like span class=typebusiness/span on each and every hreview. The review 'type' is optional. If it doesn't fit your publishing pattern, just leave it out. 4. Repeating important keywords on the page TOO MANY TIMES, such as the business name on every review: span class=item a class=include href=#review_itemMaharishi Ayurveda Health Spa/a /span This added the page main keywords so many times that I suspect it borders keyword spamming in the eyes of the search engine. Can you provide more info than that you ‘suspect’? Obviously that's a serious issue if true, but these hyperlinks are linking to fragments within the same page, not to other resources. To the best of my knowledge, that has nothing to do with establishing keywords for a page. Is there documentation to the contrary? 2. Use Google's cut down version of microformats. This may not follow the spec, but if we follow google most of our problems are solved. What I like about many google APIs is their practical approach. In that case I think their view of microformats is more practical then the spec. It certainly solves a lot of our problems. Again, can you provide a link to this? Google's Rich Snippets documentation provides some small examples of hReview, but links to the microformats spec as the definitive reference. I'm unaware of any ‘cut down’ version of microformat specs from Google, nor can I see anything in their examples suggesting this. 4. Direct feed to search engines in proprietary formats. We will still support hcard for the business directory, but will remove support for hreview since this is the major source of problems. Since search engines don't currently accept any alternative ‘direct feed’ format I don't quite know what option 4 is supposed to entail, and again, precise clarity of major problems makes the issue easier to work with. Advice is welcome and appreciated. I would really appreciate: ** An example that shows how to build a REAL reviews page. ** 1. That page includes the business information once and only once on the page, where the business name is in H1 (in hcard). 2. That page includes review aggregate, which does not require any repetition or hidden text. 3. A few reviews of the said business, WHICH DO NOT REQUIRE ANY REPETITION of any item information, the type of business, etc. 4. Business name shows once and only once on the page in the hcard and nowhere else. 5. Listing type (business/product) shows once and only once on the page. Natural place in the hcard, but according to the spec it is not possible. I'm now a little confused. Up to now you're talking about hreview, and now you refer to hreview-aggregate. As far as I'm aware, the `hreview-aggregate` can be created without any repetition or hidden text. The item will be a child of the aggregate. The subsequent reviews would need to use the include pattern to reference the original item to avoid major repetition. Currently, there is no other way. Now, I've asked questions here because you've been quite imprecise with some of your
Re: [uf-discuss] Re: An Inconvenient hCard
On 24 May 2009, at 07:19, Julian Rickards wrote: You have: div class=telspan class=typeabbr title=workNuméro de téléphone/abbr/span: span class=value(705) 123-4567/span/div The TYPE is still Numéro de téléphone because the class=type is on the span, if you move the class=type to the ABBR then it would pull the @title value of work. It is also possible to use the new value-title pattern instead. If you are still having problems, let me know. On Monday, I will give this a try and let you know how it works: thanks for the extra effort to help. So, using the new internationalisation friendly value-class pattern, what you want here is either: div class=tel span class=type span class=value-title title=work /span Numéro de téléphone /span: span class=value(705) 123-4567/span /div — this will have the en-us ‘work’ invisible Or div class=tel span class=type span class=value-title title=workNuméro de téléphone /span /span: span class=value(705) 123-4567/span /div — This keeps the ‘work’ value as a tool-top, should you want that for any reason. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: An Inconvenient hCard
On 22 May 2009, at 11:09, Julian Rickards wrote: I thought you might have the answer to the problem I am having with our French contact pages. Our English contact page (http://www.mndm.gov.on.ca/mines/lands/pro/contact_e.asp) works fine but the French contact page (http://www.mndm.gov.on.ca/mines/lands/pro/contact_f.asp) misses the phone number because work is not a French word and therefore I can't use it but must use the French equivalent instead. I have tried both the abbr-pattern as well as the value-class-pattern and neither insert the phone number into a downloaded vCard. Any ideas would be appreciated. Internationalisation is certainly an incorrect usage of the abbreviation pattern and should be avoided (the English title will be exposed to your French readers). The value-class-pattern is the correct way to mark-up this content, but, because it is very new, parsers are still implementing support for it. That's why you probably don't see it in downloaded vcards yet. This will improve over the next few months. Which parser are you using to do the conversion to vcard? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: An Inconvenient hCard
On 20 May 2009, at 04:44, Ciaran McNulty wrote: On Wed, May 20, 2009 at 12:30 PM, Mirko Gustony mirko.gust...@gmail.com wrote: making my way through the microformats I stumbled upon the type-internationalisation issue. Are there any news how to mark up a type for fax in microformats without misusing abbr? There's recently been a lot of work on the value-class-pattern [1] One of the examples is given as follows: p class='tel' lang='en-gb' span class='type' span class='value-title' title='cell' /span mobile /span span class='value'+44 7773 000 000/span /p This would seem to have obvious uses for i18n. Correct. The pattern is part-written for this exact user case (As a Brit, I've been loathe to the ‘cell’ / ‘mobile’ issue since I first got into microformats.) The value-class-pattern is valid for `type` in `tel`, and also in `adr` and `email`. FWIW, whilst we inherited these structures from vcard, I'm confident we will never create anything like it again. The community is more internationalisation aware now. A remaining to-do task for the pattern development is to update examples in the specs and related documents (datetimes and enumerations alike). Feedback much appreciated on the pattern (but please see the short http://microformats.org/wiki/value-class-pattern#FAQ as well.) Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Watching watchlists properly: the lack of an email setting
On 23 Apr 2009, at 09:35, Tiago Rodrigues wrote: Mediawiki supports this functionality since version 1.5, and since the Microformats wiki was upgraded last November to version 1.13, this funcionality exists, but is deactivated. I'll take a look into this. The functionality should be available. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] value-title design pattern
Hi Robert, Thanks for your feedback on the value-title work. It's moving along quite nicely. On 6 Feb 2009, at 03:04, Robert O'Rourke wrote: Anyway there was a bit of discussion on strackoverflow and a clever chap called Cristoph suggested using the VAR tag. I'm not entirely clear whether it's semantically valid to use to store a datetime in the title attribute but the spec states it's 'an instance of a variable'. Is that geared towards marking up code rather than an arbritrary variable? The thread on stackoverflow is here: http://stackoverflow.com/questions/457366/disabling-browser-tooltips-on-links-and-abbrs Cristoph's suggestion is at the bottom. Your guess is correct: var is for marking up code, not embedding data; here's a lot of computer science bias in HTML4. One of the key design goals I have with the new pattern is enabling choice. Whilst the semantic validity of ABBR use is oft debated, and the accessibility issues are proven, there's always been a problem and discomfort from forcing use of a particular element onto authors. The new pattern is, as mentioned on the test page, mark-up agnostic (you can use span, or b, or input, or var, or whatever you like). As such, you can publish something like Cristoph's pattern if you want to. You would do this, just adding the existing value-excerption pattern ‘value’ class to the var. p The party is at dfn class=dtstart10 o'clock on the 10th var class=value20051010T10:10:10-010/var/dfn. /p Personally, I don't agree with the uses of those elements here. I should have a followup on the value-excerption work next week, along with a draft spec. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] 2009
So, I went and blogged my vision, thoughts and spontaneous musings regarding the microformats community, microformats and the work I'd like to do over the next 12 months. http://ben-ward.co.uk/blog/microformat-2009/ I'd like to encourage you all to write up your own outlooks and vision for the year (or link to any you've already written) and I'll throw them together on a blog post on microformats.org. Write them on your own personal blogs, of if you don't have a blog, create a page under your User:You section of the wiki (e.g. `http://microformats.org/wiki/User:BenWard/microformats-2009 `). Regards, B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Bioformats - microformats for biology
On 24 Jan 2009, at 08:49, Manu Sporny wrote: li...@ben-ward.co.uk wrote: This community very intentionally doesn't try create specifications for everything. Previous pure-science efforts such as species died because it fell way outside the area of active interest of most of this community's participants. Apologies to anyone still working and implementing species work. I'd underestimated the traction. My point about collaborative interest being an important part of a microformat developer stands, but clearly my example was wrong. Sorry about that. While I do agree that it's important that this community is careful about what it works on, we shouldn't be exclusive and we shouldn't assume that we know where certain community members want to focus their attention. If a couple of people want to come into the Microformats community to develop their vocabularies, we shouldn't say that there isn't a place for them. Absolutely *anyone* should be welcome to work within the process of this community on use its resources (both people and tools) to support their work. But, in being welcoming we mustn't be closed to the idea that some groups or subject matter won't fit with us and could be more successfully developed in a different manner. We share the class attribute, and we are but one citizen in HTML semantics. I, for one, would be interested to see how a bioformats discussion would evolve *ba-dum-bum* =P FNAH! Ahem, yes: I'd be interested to read along with it and see the work happen here, for sure. (Aside: Personally I'd have nothing to contribute until later in the process when they reach the point of wanting peer review from the POV of it being a ‘microformat’, and so on, rather than the actual semantics expressed in it, but I would be prepared to offer that sort of input to as many specs as I can afford the time to assist.) Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] MediaWiki plugin
Update on this: We've added the ReCaptcha extension to our MediaWiki install, which provides a visual and audio captcha to the sign up process, against brute force password login attacks and a few other scenarios. It should significantly raise the barrier of entry for spam bots. Critically, it doesn't add anything to logging in or editing pages, so your regular workflows should be unaffected. Let me know if you have any problems, Thanks, Ben On 5 Jan 2009, at 01:05, Toby A Inkster wrote: I don't know much about MediaWiki, but surely it's possible to create a plugin which looks at edits from users with no edit history, and blocks the edit if and only if it seems to create a one- word paragraph at the top of the page? That would kill the majority of this rubbish: http://microformats.org/wiki/Special:RecentChanges -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] MediaWiki plugin
Hi Toby, On 5 Jan 2009, at 01:05, Toby A Inkster wrote: I don't know much about MediaWiki, but surely it's possible to create a plugin which looks at edits from users with no edit history, and blocks the edit if and only if it seems to create a one- word paragraph at the top of the page? Maybe. And, yes, probably. Alas, the plugins I've written for MW are just simple parsing extensions, more complex stuff I've no idea about the capabilities. I've created a new issue under wiki-2-issues (http://microformats.org/wiki/wiki-2-issues#Spam ) for this one. If we could try to collect notes of things we think should be enhanced with MW extensions over the next week (on wiki-2-issues), then we'll push the most urgent onto the microformats blog and around our various networks and see if someone more experienced with MW can help us out. Of course, if that person is already on µf-discuss, help us Obi-Wan Kenobi, you're our only hope! B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] MediaWiki plugin
Hi Martin, thanks for your comments. On 5 Jan 2009, at 12:05, Martin McEvoy wrote: It looks to me like the wiki is being spammed by a bot or bots, I have suffered problems like this. The wiki has been spammed for a long long time. The the past, the admins watch changes come through the #microformats IRC channel and kill spam as it happens. That, surprisingly, has scaled OK until we upgraded MediaWiki, which didn't work with our current IRC bot… meaning we nolonger get a live stream of updates, and instead have to check the Recent Changes page manually. Restoring the IRC bot (or an XMPP+IRC version, ideally) is another desired plugin. I stopped it by changing the form names to to something gibberish, nothing standard wpTextbox1 would be come ZifG5ut nonsense basically, a good Idea is to change the form names regularly, then you can encode the submit, preview and show pages buttons in Java script and insert them using a function. Its effective because most people who run bots to spam wikis and blogs dont want to be bothered creating a special script just for your site, they go for the low hanging fruit, the easy money and in the end its nothing personal they just move on ;-) The problem with this solution for us is that we are keen not to change code in the MediaWiki core, as it makes future upgrades for security patches more difficult. The reason it took quite so much work for me to do the last upgrade was from changes being made to core code rather than added as extensions, so I'm loathe to do anything too drastic. Unfortunately, MediaWiki is built in such a way that the form mark-up is all generated out of the core, rather than templates, so we can't adjust field names, and doing so (and adjusting the form handling) would definitely fall into ‘drastic’ core hacking. I've got a bit of time this week before I go back to work, so I'm trying to take on a number of outstanding µf issues. I'll try and look into anti-spam extensions some more. Cheers, Ben Ben Ward wrote: Hi Toby, On 5 Jan 2009, at 01:05, Toby A Inkster wrote: I don't know much about MediaWiki, but surely it's possible to create a plugin which looks at edits from users with no edit history, and blocks the edit if and only if it seems to create a one-word paragraph at the top of the page? Maybe. And, yes, probably. Alas, the plugins I've written for MW are just simple parsing extensions, more complex stuff I've no idea about the capabilities. I've created a new issue under wiki-2-issues (http://microformats.org/wiki/wiki-2-issues#Spam ) for this one. If we could try to collect notes of things we think should be enhanced with MW extensions over the next week (on wiki-2-issues), then we'll push the most urgent onto the microformats blog and around our various networks and see if someone more experienced with MW can help us out. Of course, if that person is already on µf- discuss, help us Obi-Wan Kenobi, you're our only hope! B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Martin McEvoy http://weborganics.co.uk/ You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive. Dr. James Lovelock, The Ages of Gaia ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hrecipe Draft now online *!!!!*
On 3 Dec 2008, at 09:49, Thomas Loertsch wrote: hRecipe is now a draft, linked from the frontpage. time to celebrate (a little) and scrutinely proofread, critizise and polish the sweet little bastard... http://microformats.org/wiki/recipe. I've already requested that the existing recipe-issues page be fully updated to track changes and decisions made in the move from Phae and my brainstorm to this draft. As per, new issues should be filed on the recipe-issues page. a few notes right away: * i'm not so sure about who is named editor, author etc. please feel free to change as appropriate Phae and I authored one of the original brainstorms, and if that's the one that this was derived from, I'm happy with the credit. Naming the yourself as editor is fine by me (since you've obviously just edited this draft together and Frances and I stepped back a while ago when we couldn't find time to commit to it), so as long as you're prepared to take on the workload of managing issues, that's fine too. I'll wait for the issues documentation to be completed and then follow up. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Wiki 2.0 is alive!
Hi everyone, As promised, the wiki had some downtime this evening as I ran a fairly large upgrade of MediaWiki and the design of the microformats wiki. It's been quite a long time coming, and a lot of work, but I hope people appreciate the improvement. The new features of the wiki are documented on the wiki itself[1], along with an issues page[2]. You can also get a drive-by idea of what kind of improvements I've made by visiting the frontpage[3], the hCard page[4] and the hAtom page[5]. Feedback is welcome as always, either here, on the aforementioned issues page or on the associated blog entry[6]. 1. http://microformats.org/wiki/wiki-2 2. http://microformats.org/wiki/wiki-2-issues 3. http://microformats.org/wiki/ 4. http://microformats.org/wiki/hcard 5. http://microformats.org/wiki/hatom 6. http://microformats.org/blog/2008/11/17/wiki/ Thanks for your patience with the upgrade. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Wiki issues - no login required?
Hi David, On 17 Nov 2008, at 14:15, David Janes wrote: Is the Wiki supposed to be no login required? Just noticed that I can edit pages without being logged in. The setting used to enforce that seemed to have changed between MediaWiki versions, thanks very much for catching this! I've disabled anonymous login rights again. Hopefully we'll get spammed a little less now! Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern
Hi Mike, On 9 Nov 2008, at 09:32, Isofarro wrote: Where a value-classed span is used and a human friendly wording is used as inner text, then in case 2.) the machine formatted data is read out, but not the human-readable version, and in case 3.) the machine formatted data is read out before or after the human friendly data. So the accessibility barriers that are created are: 1.) machine-formatted data is being read out to screen reader users 2.) machine-formatted data is being read out, and its human digestible format isn't. Both cases result in content that is more difficult to understand, but case 2 is actually worse - it replaces human readable content with machine readable content. Both introduce accessibility barriers, just one does more damage than the other. So, I believe I'm reading this right that you're describing a value- classed + inner text + title situation all on the same element, and *not* where you have the value-classed element as an empty sibling of the human form (which is what the current proposal specifies)? With this in mind, from an accessibility perspective, any microformat pattern which results in machine-formatted or human- unfriendly content in an area that is supposed to be human consumable is going to create one barrier or the other, depending on screen reader configuration. So the logical approach to protecting the accessibility of the page in these cases is not to use any microformat that specifies adding machine data into a human-visible region of the page. Again for clarity, could you confirm whether the proposed pattern falls into your definition of introducing machine-data into a human- visible region of the page, given that the empty elements are ignored in the page rendering. e.g, in hAtom: span class=updatedspan class=value title=20081116T073000+0800/span16th November 2008, 7:30am/span Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16)
Hi everyone, An update to the microformats wiki is finally ready to go live (updating to the new build of mediawiki, plus some new theming features and plug-ins). I got delayed quite a bit due to my moving out to San Francisco, but all being well I'll be running the update on the afternoon of Sunday 16th. This process will take a few hours. The wiki will be read-only throughout the process, and there will be brief downtime whilst the installation is swapped over. If this is going to cause a problem for anybody, please shout out! Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16)
On 11 Nov 2008, at 15:42, Dan Brickley wrote: Ben Ward wrote: Hi everyone, An update to the microformats wiki is finally ready to go live (updating to the new build of mediawiki, plus some new theming features and plug-ins). Good luck with the switchover! Any chance of openid for logins in the new version? Adding OpenID support was something I was really keen to do, and has been a long running requested feature. However, the current state of the OpenID extension for MediaWiki is overkill for us. The plug-in that's available transforms the wiki into a full on OpenID _provider_, and we don't want the maintenance/responsibility cost of doing that. We just want login support. So the task has been deferred pending someone writing a super-simple OpenIDLogin plugin, or dedicating longer to the existing extension and getting it installed properly. It might not take that long to do the latter, but it's a more substantial installation than other extensions, so I'm preferring to get the current work released with a view to adding it later. Given the way in which microformats.org is spread across multiple platforms (the wordpress blog, mediawiki, various API kits hosted on Google and elsewhere), I'm certainly very keen to have OpenID as a feature on everything we do. New features are approximately listed on the microformats todo list here: http://microformats.org/wiki/todo#Wiki_2.0 and will be documented more thoroughly on the wiki itself when we do the upgrade. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern
Hi Rob, On 7 Nov 2008, at 11:40, Rob Crowther wrote: span class=dtstartspan class=value title=2008-11-04/span Barack Obama was elected the first African American president of the United States of American, and he was really pleased about it, on 4th November 2008/span Basically I'm not clear how forcing the empty element to be the first thing guarantees that it will then be close to the plain text date. Forcing it to be anywhere would seem to guarantee there are situations where it can't be close to where the plain text date is if the original example is valid, because it's easy enough to have that sentence the other way around. Requiring the machine data to be the first child element is not to force it to be close the human form (which is in an indeterminable position in the structure), but instead to force it to be close to the *property declaration*. The idea is that when you read the mark-up, you read the machine-data value right next to the property name; a visually clearer association that will make it easily to see and maintain the value when working the code. Visual developer aids (such as CSS rules to display the @title attribute of elements with class=value during development) will cause the value to be displayed at the beginning of property blocks, again promoting a stronger visual association. It means that the machine-data value doesn't get lost within a block of content, it's there right at the start, and that attempts to alleviate the violation of DRY. I most cases, I expect patterns will be simple, and end up containing just the machine value and displayed form with no additional content. By forcing the machine-data to the front though, it remains consistent no matter now much content is contained in the display form. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern
Hi André, On 7 Nov 2008, at 08:38, André Luís wrote: I can see this option being adopted by people who are concerned about accessibility, while others might just go ahead and use the regular-problem-maker-of-a-pattern the datetime design pattern, preferring simplicity over accessibility. Right? Well, first up, all web developers are supposed to be concerned about accessibility, otherwise they're not doing their job properly. I'll avoid digressing into that, though! All optimisation patterns in microformats are valid for some purposes. Using an ABBR for country names is completely the Right Thing To Do, whilst for a timestamp it may not be. As with many methods in HTML, a degree of author interpretation of semantics will always take place, and authors will implement what makes sense to them. There has to be an acceptance that valid HTML4 does not allow for embedding alternate-form content, so we're trying to build something that fits as logically and gracefully as we can. For me, the ‘machine- data’ value being a child of the property (a sibling of the display form) makes total structural sense. An advantage of this pattern is that it is based entirely around neutral mark-up (span), although there is also no need to restrict it to any one element (you can use b class=value if you like, or input type=hidden class=value if you want; we and our parsers shouldn't and don't care). Using the @title attribute of this value element when the user does not want the value to be displayed is a little cludgy, but justified by the fact that it is not rendered in any browser (although that behaviour is a specification grey-area). Despite a stretch over the traditional use of title, @title is still associated with the class=value element. I think they have a valid and appropriate relationship; I read it as ‘the title of the value is 2008-11-07’. It's not as strong a relationship as the inner-text, but it's not nonsense, either. There is also a viewpoint that @title should only be for human consumable data. I agree and subscribe to this viewpoint. But in this mark-up pattern, the @title of an empty element is never exposed to ANY human in any way — that has been tested by the lovely James Craig of Apple, who has confirmed that empty spans do not get exposed to screen readers (although empty abbr elements can). Thus, I think the benefits and grace of the structure justify that exception. This is also the line of exception I would make when writing coding standards. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern
Hi everyone. So, a few months ago I was working on the ongoing value-excerption- pattern specification. Then I moved to San Francisco and my work went a little stagnant, but I'm trying to pick it up again. The value-excerption-pattern is an attempt to fully spec the class=value behaviour from tel in hCard, which has since been supported globally in some parsers for a while, and has proved somewhat useful. In addition to fully spec'ing the behaviour for parsing class=value elements for visible data, I've been working on additional specification to handle inclusion of machine-centric data alongside human forms (http://microformats.org/wiki/machine-data). It's this machine-centic portion that I'm trying to nail down at the moment, since it would provide an in-demand solution for various recurring complaints (abbr-pattern dependencies, for example). Also, note that recent brainstorming regarding patterns dervice from the semantics of the object element and value excerption has shown that current, in-use browsers (Microsoft Internet Explorer and Apple's Safari 2) do not handle object acceptably for inline content (http://microformats.org/wiki/value-excerption-pattern-brainstorming#object_param_handling ). So we're definitely stuck with needing to spec this pattern using generic mark-up. (http://microformats.org/wiki/value-excerption-pattern-brainstorming#object_param_handling ) Since it's been a while, this mail serves to summarise the current state of this spec and proposed resolutions to open issues. PLEASE, if you have additional issues to raise, add them to the wiki page (http://microformats.org/wiki/value-excerption-pattern-issues#Parsing_title_from_Empty_value_Elements ) Couple of Examples: span class=dtstartspan class=value title=2008-08-27T23:25:00-0700/span 11:25pm, August 27th 2008/ span p class=tel span class=typespan class=value title=cell/span Mobile/span span class=value415-123-4567/span /p Purpose --- This pattern allows you to embed fixed format content — such as the telephone type enumeration and parser-required data formats — alongside the visible format of the publisher's choice. Responses to Issues so Far -- 1. DRY Violation worse than current ABBR-pattern. DRY is a problem when data is repeated in a document and risks one copy of the data not being maintained in sync with another. Maintenance of the document results in broken data. Resolution: To address this, the empty-span part of the value excerption pattern will specify that the empty-span MUST be the first, non-whitespace-text-node child of the property element. Thus, this will parse: span class=dtstartspan class=value title=2008-11-04/ span4th November/span But this will fail: span class=dtstartOn 4th November 2008 Barack Obama was elected the first African American president of the United States of American. He was really pleased about it. span class=value title=2008-11-04/span /span The first pattern keeps the code distance small between the data form (class=value) and the property name (class=dtstart). It disallows the machine-data portion from being separated from the property. Furthermore, the spec should encourage conformance checking tools to attempt to verify the machine date form against the human form and warn the user if they data does not match. 2. Violating the principal of visible data Resolution: Microformats maintain a principal of marking up visible data. However, we have exceptional circumstances where the data required for parsing is not the data that publishers wish to display. Whilst parsers are a lower priority than publishers, the cost and complexity of parsing unstructured dates, or translated terms, is accepted as too high. Therefore it is necessary to violate DRY to include explicit representations for machines. Currently authors may use CSS to hide the machine-form of dates. Microformats exists only in the HTML layer, and must not depend on CSS to meet publisher requirements. The specification may also restrict this part of the pattern to certain properties where a machine-data form is required, as a means to discourage abuse. 3. Broken parsers drop empty elements There are some broken but widespread HTML parsers which discard empty elements, resulting in the empty-span-value element being removed from documents (e.g. HTMLTIdy). HTMLTidy is easily patched not to do this, but may already exist in publishing platforms. Resolution: Without numbers, we don't know how many publishing systems would be affected but this. It's a problem for which the only resolution is to use a completely different pattern. As such, this proposal must put legacy broken parsers down as an accepted loss. CMS's locked to old versions of HTML Tidy would not be able to use this pattern without
Re: [uf-discuss] Yahoo Profiles
On 17 Oct 2008, at 13:54, David Janes wrote: I just read [1] about Yahoo's new profiles. Does anyone know if Microformats are supported? There are some. You connections have hcards, although there's an error with class='photo' not being added to an IMG element (instead a parent). I've filed bugs for the addition of hcard to profile pages themselves and XFN to connection relationships. Thanks, David. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] indexing microformats
On 2 Oct 2008, at 02:18, Ted Drake wrote: Search monkey provides hcard and I believe hevent directly to the developer. It's a great use of microformats. SearchMonkey parses microformats and associates that data with search results, but at this point the data is not queryable. (e.g. you can't search for ‘pages with an hatom published date of today’ or ‘pages containing an event located in London’). You can only access that info once you have the results of a more conventional search query. SM is still excellent, I just mean to clarify that it is not an indexer of microformats. B -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Suda Sent: Thursday, October 02, 2008 12:35 AM To: Microformats Discuss Subject: Re: [uf-discuss] indexing microformats On 10/1/08, Karsten Januszewski [EMAIL PROTECTED] wrote: What tool or services are out there that index and tabulate Microformats as such? --- Both technorati's pingerati and alexa were good sources of data. Yahoo's search monkey allows you to style search output, but i don't think the microformatted data is directly exposed. Another question: how do people feel about the use of the word Microformat as a verb or adjective, aka microformatted content or can you please Microformat that page with an hCard? --- that's a good question! I know there has been some effort to make microformats lower-case 'm' as well. You might also consider adding that question to the FAQs page, then we can all work on an answer together http://microformats.org/wiki/faq or possibly start a new page http://microformats.org/wiki/usage (maybe)? to help describe how to, or how freely you can, and in what context the term 'microformat' can be used. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] URL and Relative paths
Hi Karsten, On 2 Sep 2008, at 17:23, Karsten Januszewski wrote: Hi - I'm a developer at Microsoft working on a project that involves parsing and consuming Microformats. I've noticed quite a few implementations of hCards out in the wild that use the url property with a relative path instead of an absolute path. This is completely valid. Publishers mark-up URLs just as they would for any hyperlink in their page. Anything that's valid in the href attribute is valid in hCard. It's very much the role of the parser to handle URLs in all their applicable forms. I didn't see anything on the wiki about this... There won't be anything specific on the wiki because there are no restrictions over the existing usage in HTML. Good luck! Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force
On 28 Aug 2008, at 12:24, Manu Sporny wrote: It will take a couple of weeks to give examples of how this will all work, but I wanted to get feedback from this community before proceeding. We have a fantastic opportunity in front of us now - who in this community thinks that we should work with the W3C on this endeavor? I'm not sure I completely see the benefit in this, and seeing your examples would be very helpful in getting a better idea of what you're proposing. From your bullet points, it seems to suggest taking microformat vocabularies and expressing them in RDFa, rather than HTML? It seems redundant for publishers. However, I do have a somewhat related issue that you might consider part of this effort. Some discussions I've had lately revealed usefulness in being able to _map_ microformats into RDF, for the purpose of combining microformats with other RDF vocabularies in a back-end somewhere (so, conversion for processing, rather than publishing. Publishing remains in HTML where it is most effective). I'm told that RDF ‘versions’ of vcard and icalendar are out of date compared to the microformats. As such, it strikes me that rather than maintaining duplicate specifications, it would instead make sense to develop a set of standard transformations so that any microformat can be transformed from HTML to RDF, without requiring duplicate effort to maintain another spec. This I'm sure would relate closely to GRDDL, since that already deals with transformation. This latter issue seems valuable, and preferable to a situation where every processor of microformats and RDF comes up with their own incompatible conversions. Note, I'm talking about mapping rules, not separate specs. For example, we have the ‘jCard’ page on the wiki, which I still feel should be more generic ‘JSON Mapping Rules’ page that can cover parsing from any format, not just hcard. If this RDF mapping effort is pursued by anyone, I would again favour ‘RDF Mapping Rules’, rather than ‘rCard’, ‘rCal’ and ‘rListing’ — duplicate specs not based in HTML are not something that this community was founded to produce. Cheers, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Draft to Specification (was: [uf-discuss] More than three years)
On 27 Aug 2008, at 17:38, Zachary Carter wrote: What does it take to bump a draft, say hResume, to spec status? Just resolving the remaining open issues, or is there more to it? It's definitely something that people are unclear on. On my part I've been thinking a lot regarding ‘the role of editors’, spec status and so forth. My moving to San Francisco this month has pretty much neutralised my ability to contribute whilst I find an apartment and get settled in the US. The sunshine is awesome, though. I will get it written up fully, but in short, my view is that spec editors need to be ‘actively’ working on their spec (for some value of active, with some *simple* conditions for passing editorial control of specs away from inactive/unsuitable editors when demand arises). In my view, a specification goes from draft to ‘release’ when all issues are resolved in some way, and issue resolution should be a simple enumeration, probably one of ‘fixed’, ‘invalid’ or ‘deferred for future iteration’. Some clause needs to sit in place to ensure that specs are suitably vetted — we don't want someone creating a spec quickly, fixing a small number of raised issues and declaring something a spec just because they reach the ‘issues’ finishing line. It absolutely needs not to be a ‘finishing line’ at all. Maybe each spec should have a required minimum draft iterations before it can go 1.0, allowing people to participate at different levels. Those passionate about subject matter will take interest at the 0.1 stage, those who are simply active within microformats in general would review specs at the second or third draft to protect against process violations and fast-tracking. I wouldn't want anything too strict, but all specs iterate draft versions anyway, so it might be wise to map them to cue issue review. It's also worth saying that I'd want to avoid ‘spec status’ being misinterpreted as something being ‘finished’. Specs should always be open to evolutionary iteration. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML5, Microformats and RDFa
On 25 Aug 2008, at 19:47, Manu Sporny wrote: There have been several threads discussing Microformats, RDFa and HTML5 that are occurring on the WHATWG mailing list. The discussion relates to whether or not HTML5 should depend on the Microformats community to solve HTML5's semantic markup issues, or if both Microformats and RDFa should be considered for semantic web markup issues. I've been out of touch with HTML5 development for a bit, but the way you describe this paragraph is somewhat alarming. We, the microformats community, absolutely *should not* be relied on the fill every gap in HTML. That they would not specify minority concerns in the HTML language is perfectly understandable, but the Microformats Community is itself not designed to do that either. This community, with this development process, is completely inappropriate for filling every single extended use for HTML that people might have. HOWEVER, there may just be misinterpretation here. Perhaps rather than intending to depend on our specific community, the intention is that the gaps be filled with ‘microformat-like patterns’. Patterns, class- patterns, ‘posh’… whatever you want to call it. Microformats.org does not own the class attribute and anyone working on techniques that are incompatible with our process can do so. It seems to me the case is not about ‘microformats.org’, but instead about the capabilities of the class attribute itself. Is it just that the word ‘microformats’ is being used as a generic catch-all for semantic class name patterns? It seems quite reasonable that the HTML working group be considering the use case of ‘extended semantic description in HTML’ and considering its existing capabilities (which are proving very capable in the specific case of microformats), rather than a use case of ‘support RDFa in HTML’, which is just one solution. I think Scott is correct in that you may need to reframe your argument. Any push to have RDFa made a part of HTML5 should be focused on the capabilities of RDFa compared to the class attribute, not the (often intentional) limitations of one particular user of the class attribute (us). Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] NetNewsWire ditches support for microformats
I'm also a long time NNW user, and haven't seen the Microformats UI in over a year. On 16 Aug 2008, at 09:41, Chris Messina wrote: * Are microformats valuable in client-side applications? * Should their presence be made known to end-users? Where there is data that can be converted, should an interface be provided to do so? * Is adding hcards to address books and hcalendars to calendars really the best possible value of adding microformats parsing to an application? If not, what other application has demonstrated additional, or different, value? I don't think it takes much argument to say that microformats can and will be useful in client UI, but the NNW UI specifically was not the right solution. I think there's potential to do far more ambitious UI that used microformats which would be far more useful to end users and more inspiring to authors. NNW has a source list down the left hand side with ‘Latest News’, ‘Flagged Items’ and ‘Clippings’. An ‘Upcoming Events’ item in there, generated from hCalendar in feeds (and optionally exposed to iCal as well) would, in my brain-farting mode, be a far more engaging prospect for users and publishers. The NNW UI was a great little experiment, but authors need more substantial ideas to encourage them to publish more. If Newsgator were saying ‘use hCalendar — it's a standard!’ and link it to some UI in their software, I think they'd get interest. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
On 16 Jul 2008, at 11:28, LucaP wrote: I believe this new HTML feature found in the HTML 5 draft specification should be taken into account in here, since it is relevant to many ongoing discussions... http://www.w3.org/html/wg/html5/#custom In addition to the existing replies, and the fact that microformats are currently designed to work in HTML4 and not unstable drafts, quoting the specification itself: User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values. -data prefix attributes are, by design and intention, for use by individual applications. They are explicitly excluded as a mechanism for microformats and the like. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Scheduling Wiki Downtime
Hi everyone, One of my admin tasks at the moment is to run an upgrade of the Microformats Wiki. Critically, this is to upgrade our install of MediaWiki to the most recent release, but also taking the opportunity to add some new microformat-friendly enhancements to the install, and to the theme. You can see the list of features/improvements I've been hacking on here: http://microformats.org/wiki/todo#Wiki_2.0 The work is nearly done, and running the upgrade is possible in multiple steps, but it's going to require some — hopefully short — periods of downtime to apply the updates. Critically, MediaWiki has to change the structure of the database between versions, so the wiki will need to be taken offline whilst that process runs. My intention is to run this upgrade on Sunday 20th July (next weekend), sometime in the afternoon GMT. As such, if you're planning any work for that afternoon that requires you to refer to microformats documentation, please take an offline copy. The wiki should only be offline for a couple of hours. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats to describe a broadcast
Hi Tom, Is anyone aware of any other programme guides which have employed the hCalendar microformat to date? I note that this doesn't seem to have been acheived in the current BBC listings. We've got hCalendar on all of Yahoo's UK TV listings: • http://uk.tv.yahoo.com/listings/2008-07-11/20-30/ • http://uk.tv.yahoo.com/listings/2008-07-11/20-30/by-hour/ • http://uk.tv.yahoo.com/listings/bbc-1/2008-07-11/ We implemented it using a somewhat icky hack (an empty ABBR element with the ISO date in the title), but it parses in most parsers whislt not exposing the ISO date as a tooltip to browsers. Most recent testing suggests that it will still be revealed in screen readers set to read ABBR titles though, which is unfortunate. Oh, there's a bug in our output that's putting a translation string (%z) into the ISO date where the timezone should go. That'll be fixed shortly! B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Reviving hProduct
Hi Jay, On 7 Jul 2008, at 17:11, Jay Myers wrote: All, It seems like the hProduct microformat hasn't seen a lot of revisions since it's initial brainstorming in 2006 (feel free to correct me on this if there are current efforts taking place :-) ). I'm attempting to revise the schema for use in an upcoming August / September project release. I have taken the current brainstorming schema and added on some new items. I would like to open this up to discussion and move this format forward, and any assistance the community would be able to provide would be helpful. It's great that you're keen to take a lead on further brainstorming. Please conduct work on new microformats on the [uf-new] mailing list, rather than discuss. Thanks! Altered schema: http://jay.beweep.com/hproduct/hproduct-schema.txt Unstyled HTML example: http://jay.beweep.com/hproduct/hproduct-example.html The old product brainstorm is discarded, so please edit the wiki. Either start a fresh brainstorm section on the current page, or work with the existing text. The altered schema: For reference, much of the schema you describe there has been rolled into hListing, which whilst also technically a proposal, is more mature and has been implemented successfully by a number of people. That covers the price/merchant side of things. The documentation for listing, and interating on it to reach draft also needs doing, I apologise for not following through my intent to take a lead on that. Lots of other µf things have come up that always seem more urgent. I'd suggest that product-specific fields focus on the product _item_, e.g. where you have .hListing .item, or .hReview .item, you could insert an ‘hProduct’ there, enhancing the semantics, and achieving listing products with prices through the formats being used in combination. Regards, Ben (This post has been cross-posted to µf-new. Please reply *only* to µf- new) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Wiki Documentation of recent date-time discussion
Hi all, Recently discussion of solutions to the datetime issues has been massive and become difficult to track the current state of issues and counterpoints as threads have become interleaved. I have *attempted* to document the most recent points on the wiki, under the following pages: * http://microformats.org/wiki/datetime-design-pattern (most stuff) * http://microformats.org/wiki/hcalendar-issues#2008 (for the HTML5 time element) * http://microformats.org/wiki/value-excerption-pattern-issues I've credited the points added with the name of the post author. If you feel the part I've quoted doesn't fully represent your view, please edit it. I've done the best I can, but these threads have become very difficult to follow so I sincerely apologise if I've missed something, or lost track of something. If a point is missing from the wiki threads, please add them so we have a reference. Ideally, wiki discussion should not be a carbon copy of the mailing list logs. They should be a concise representation of issues, and each issue and its counterpoints should of course only be listed once. It's a reference. Someone new to discussions should be able to read the wiki and be up to speed on what is currently being discussed on other mediums in the community. My edits today don't achieve that in the optimal way; they're largely quotes. It's better than no documentation at all, though. Something which didn't really happen this week was follow up in documenting the key points of discussion on the wiki. When you are an advocate of a particular solution, please take the responsibility to make sure issues raised against it and the resolutions are accurately documented. Otherwise suggestions will be lost without documentation and inevitably repeated without reference. Thank you, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Human and machine readable data format
On 1 Jul 2008, at 13:28, Scott Reynen wrote: The difference with ISO dates is we've previously defined them as content; I'm suggesting that's a mistaken definition, as these dates don't function as content in our reference standard iCalendar. In my view, it's not so much that an ISO dates isn't content per se, it's that it's not content for humans, and in this case, the date content for humans is being published in a different form. In HTML, visible content is for humans, content for machines is hidden. This makes for a violation of the DRY principal, but it's the same violation we're already making, and it applies not just to datetimes, but also to durations (which has only just been mentioned in this discussion, and is important not to ignore), hCard telephone types, geo co-ordinates, and everything else documented on http://microformats.org/wiki/machine-data . As an aside, this is why I favoured and have done some initial work into the empty-element-with-title extension to the value-excerption- pattern (which I'm also leading the effort to get properly specified, since it's previously not been). It keeps the machine content in the HTML, can be specified to keep it physical proximity to the human form, but due to the way empty elements are treated, does not expose that content to humans. It does not violate DRY any more than we already do and in relation to the ‘hidden data’ principal, I argue these are exceptional cases _because_ they are DRY violations. We are not hiding information, we're hiding an alternate representation of visible information. (issues page: http://microformats.org/wiki/value-excerption-pattern-issues) . Much of this same line of discussion applies to the class-name data embedding that Jake and Frances have discussed. If there's a semantically acceptable solution to this, which doesn't violate any principals, or DRY, or the semantics of HTML, doesn't compromise accessibility or internationalisation, and meets publishers demands for flexibility and doesn't compromise user experience, then that would be fantastic. None of the discussions so far seem to match that. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Human and machine readable data format
On 1 Jul 2008, at 17:01, Guillaume Lebleu wrote: Since the BBC's request was specifically related to screen readers, we may want to distinguish machine-readable, human-readable and human-hearable. I think there is less debate re: what is human- hearable than there is debate re: what is human-readable The BBC complaint directly refers to both screen readers and the display of unexpected text in tool-tips. It's not just about aural output. At the core, in breaking with the semantics of an HTML element, we've broken the behaviour of technologies using the element correctly and intelligently (hence my strong opposition to continuing to stretch ABBR outside of textual abbreviations as commonly described by dictionaries: ‘An abbreviation is a shortened form of a word or phrase.’ — Wikipedia, Apple OSX Dictionary, Dictionary.com) B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Human and machine readable data format
On 30 Jun 2008, at 16:16, Jeremy Keith wrote: Now I'm not saying that this solution is perfect but it's by far the best I've seen so far. It doesn't involve hiding data and it doesn't involve stuffing data values in the class attribute. It *does* still use the abbr element for a usage that is arguably semantically dodgy. But any solution is going to involve some kind of compromise to a greater or lesser degree and this is a level of compromise that I personally find acceptable (it also maintains backwards compatibility with existing publishing behaviour). I disagree with this. I don't think it's acceptable for us to define microformats that break with the specified semantics of HTML. Yes, it's frustrating that HTML is spec'd the way it is, but the intent of the HTML title attribute is to be for human data. The intent of the ABBR element is for human expansions. HTML4 made no provision for machine data in those nodes, and since HTML is the foundation on which we are building, I don't feel that we are entitled to shoehorn broken reinterpretations of those semantics to suit our needs. Where an existing HTML element has the correct semantic to use, we should use it. Where an existing HTML element does not exist, we must resist using a ‘nearest fit’ when that ‘nearest fit’ is still incorrect. We must not limit the usefulness of the true, intended semantics of that element by stretched its semantics. HTML has generic, semantic-less elements for when nothing else matches. We should use them. Further, with specific regard to this proposal, whilst the examples being cited are closer to valid, human abbreviation, it does nothing to address the popular practice of ‘5 minutes ago’ and ‘this morning’ or ‘today’ dates, which are not human, text abbreviations of a date, and the expanded form is not always contextually compatible with the abbreviated form. datetime-design-pattern#issues http://microformats.org/wiki/datetime-design-pattern#issues has these problems documented. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Vote for Microformats on Yahoo! SearchMonkey suggestions board
Hi all, Just a quick note that the Yahoo! SearchMonkey product — which allows you to enhance search results at Yahoo! with data gleaned from microformats — have a public suggestions board and are shortly going to be using it to influence their next set of development priorities. As such, now is a great time to vote up any microformat related issues that you'd like to see supported in the near future. There are currently two open suggestions: • Complete hAtom Support (current support is not returning all hAtom fields): http://suggestions.yahoo.com/detail/?prop=searchmonkeyfid=97199 • Addition of ADR and GEO microformats: http://suggestions.yahoo.com/detail/?prop=searchmonkeyfid=90532 Please add votes of support to those issues, and if you have others to add by all means go right on ahead! Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
On 28 Jun 2008, at 13:03, André Luís wrote: October Oct. And other languages, like Portuguese: Outubro Out. This, however, could be handled with abbr, without hindering accessibility. span class=monthabbr title=OctoberOct./abbr/span With the current abbr-pattern, your example should be: abbr class=month title=OctoberOct./abbr That's a perfectly valid abbreviation, but doesn't address the internationalisation issue. abbr class=month title=OctoberOutubro/abbr is not an abbreviation, it's translation. We end up with the same problem that exists in hcard with supporting span class=tel span class=typecell/span… in languages outside US English. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Using object for datetimes (was: Microformats and RDFa not as far apart as previously thought)
On 28 Jun 2008, at 17:03, Ed Lucas wrote: George Brocklehurst wrote: Is it worth revisiting Tantek's original suggestion of using the object element to represent dates? [1] The idea was to do something like this: object data=20050125January 25/object This particular example is invalid, as the data= attribute must contain a URI, and a URI cannot start with a number. display:inline and intrinsic sizing will work correctly. Safari 2.0.2, which came out in November 2005, was the first version to contain these improvements [2]. For note, I don't feel that CSS support on an element should be of consideration when designing microformats. We are operating at the HTML level and must not produce techniques which depend on them (although documenting techniques where CSS can be used to enhace/alter microformats is still valuable, I'm simply meaning that HTML+CSS must not ever be the primary solution to a problem). It might be that there are other reasons for not using object that I've missed (I'm fairly new to the wonderful world of Microformats) and it might be that there's still a significant population of Safari users on 2.0.1 or older, but if not this could be a way forward that gets around the abbr issue. I'm normally just a lurker here, but no-one has replied, so... Using the object element seems like a very sensible solution. What are the blocking issues now that Safari handles it? So, one solution I saw offered to the URIs-can't-start-with-numbers issues was to do everything as a URL fragment, converting it to: object data=#20050125January 25/object That, however, causes Safari 3 to render a box of the current page within the OBJECT element, and so would introduce a CSS dependency to keep it hidden. No good, I fear. *However*, the following appears to be well behaved inline in Safari 2.04 and 3.1.1, Firefox 1, 1.5, 2 and 3, and Opera 7, 8 and 9. object class=dtstart data=data://20080712/object That uses the DATA URI scheme, which without a specified mime type and charset, defaults to text/plain;chartset=US=ASCII. I think that would be sufficient. I've pastied my test case, and would be grateful if people could test the behaviour in Internet Explorer: http://pastie.org/224023 Given that IE has a history of abysmal support for OBJECT and no support for data: URIs… I have no idea what might happen. See also: http://en.wikipedia.org/wiki/Data:_URI_scheme http://tools.ietf.org/html/rfc2397 (data: spec) http://www.ietf.org/rfc/rfc2396.txt (URI spec) B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview limitations/restrictions
Hi Geoff, On 26 Jun 2008, at 15:01, Geoff Berger wrote: Are there any limitations or restrictions to using hReview for commercial purposes? The company I work for is looking to use hReview. However, we do not want to use if there are any legal restrictions or if the community would be opposed to it. All microformat specifications are released into the Public Domain and can be used by any person or organisation without restriction. Many commercial entities are already using microformats on a large scale; Yahoo (who I work for) publish a huge amount of hCard, hCalendar, hReview, hListing, and, err, many more. The very purpose of microformats, to better describe the information we publish in pages, dictates that *everyone* is encouraged to publish with them. Regards, B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview limitations/restrictions
Hi Geoff, On 27 Jun 2008, at 05:33, Geoff Berger wrote: Thank you very much for your fast response. To further elaborate, the company I work for charges money to an affiliate for the right to use customer reviews on their personal site. It comes down to this, does using a microformat imply that the content is free to syndicate? Would it be necessary to have a Terms and Conditions stating customer reviews are copy written or something to that degree? No, using microformats does not imply anything about the licensing of the information. In fact, the rel-license microformat allows you to make it explicit when all rights are reserved. Additional licensing restrictions you may impose apply to microformatted content just as to content without microformats. The microformats specifications themselves are completely free in the public domain. That has no effect on the material published within these HTML patterns. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Documentation of machine-data and value-excerption
Hi everyone, Over the past few weeks I've been making efforts to document some of the greyer areas of microformats and better specify how they behave; machine-data and value-excerpting. Machine data in microformats is where we specify a fixed data format (such as dates and geo), or fixed enumeration of fields (such as telephone ‘type’ in hCard). In the past it's been rather disparate, but I've now documented it all at http://microformats.org/wiki/machine-data — Thanks to Toby Inkster who's also made contributions to that page. I hope that makes a useful reference for machine data usage in µf in general, and also as documentation of how to validly and semantically include such data in pages. People who find recurring issue with some uses of the ABBR-design- pattern should definitely read the machine-data page, as it documents *all* of the currently supported and implemented ways of embedding data in pages, including *but not limited to* ABBR. Which leads nicely into the second part, which is that we're making an effort on the microformats-dev mailing list to specify the parsing behaviour of value-excerption (class=value, known as ‘value- excerpting’ in hCard). Whilst it was originally just part of hCard's TEL field, it's actually supported in parsers generally. http://microformats.org/wiki/value-excerption-pattern explains the uses and better documents the parsing behaviour. That documentation is ongoing, but since it's already implemented, I hope what we've got so far is useful. Alongside the dedicated page for value-excerption, there's a proper - issues page for the pattern, so if you have bugs or issues to raise with it, please raise them on http://microformats.org/wiki/value-excerption-pattern-issues , then we can move through them in a nicely structured manner. Now that the pages are well structured, wider feedback is encouraged. Please add issues to value-excerpting where you see them, and check the microformats-dev archive (http://microformats.org/discuss/mail/microformats-dev/ ) for what's already been discussed. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Request for help from screen reader users from the BBC
On 22 May 2008, at 17:06, Alasdair King wrote: From the BBC page linked: We've looked at quite a few screen readers out of the box and by default they don't expand abbreviation elements so the user still hears 19:30 not 2008-05-15T19:30:00+01:00. I infer that they've tested the screenreaders, they're just worried there are lots of blind people who have turned on ABBR, and the BBC is a big, sensitive target. I know blind people are more annoyed about the lack of audio descriptions in iPlayer, but there'll be some uber-geek screenreader user in a well-off advocacy group who'll complain. People who have problems will be the subset of users who (use a screenreader) AND (have a screenreader that supports ABBR) AND (have turned on abbreviation elements) AND (come across hCalendar ABBR elements) AND (find this one thing the biggest headache in using the site.) Why not just offer to buy both those people a beer to make up? I don't think the ‘what's the default‘ argument is an absolute decider either way with this. The behaviour is supported and used; we've not been able to get numbers on how many assistive technology users do turn it on, but I don't think it's right to dismiss an option of a browser which is acting legitimately with the semantics of the HTML it is parsing. Reading aloud abbreviations is a perfectly reasonable thing to do, whether it's a default, on-demand or whatever. As far as I can judge, assistive technology offering the ability to expand abbreviations is entirely in line with the intentions of the HTML4 specification, whereas stuffing illegible data into it is not. This is less an issue of accessibility as it is semantics. Where ABBR is being used incorrectly, there's no right to complain about a consuming tool treating your code in an undesired way. Recently, we've been discussing the issue of embedding machine-data as part of microformats on uf-dev, and debating possible alternative methods from a parser perspective (namely an empty element with a title attribute). Of interest here is the document now on the wiki covering all the uses of machine data in microformats, and covering all the currently supported means of including that alongside the publishers preferred formatting. http://microformats.org/wiki/machine-data At the moment, the data embedding solution proposed there is being discussed on -dev: (http://microformats.org/discuss/mail/microformats-dev/2008-May/000519.html ). It will move over to discuss once we're confident in it being reliably parsable. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] My inactivity
Hi all, Just a little note to explain that my µf tasks: hListing, ABBR- pattern, ‘This Week’ posts are on hold at the moment as I made a rather unexpected trip into hospital this week. No need to worry; after five days I've been released again (my appendix had gone rotten and has been removed). However, I'll be resting for most of this week, so doubt I'll be back onto my non-essential tasks list until next weekend at the earliest. Since we've not had one in a fortnight, if anyone else would like to put together a ‘This Week’ blog post in my absence, that would be great. Cheers, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Appropriate microformats for journal listings?
Hi Angus, On 8 Apr 2008, at 13:20, Angus McIntyre wrote: I'm editing a page that lists editions of a journal, each entry having a form something like: Title Journalname 1 (2003) - downloadlink - Article 1 Author1, Author2 (Affiliation) Article 2 Author3 (Affiliation) and so on. Are there microformats that would make sense to use here? I toyed with the idea of making the author name lines use vCard, but that runs into problems where you have multiple authors belonging to the same organization. hAtom? Seems like a very good fit with hAtom, the only complication being the presence of multiple authors which is unhandled in hAtom, and… untested… in hCard. VCARD has a concept of ‘AGENTS’, which effectively nests vcards within each other. They're unhandled in desktop software, so demand to work out parsing rules in hCard has been low. If my understanding of AGENT is current, though, this seems like an appropriate place to use them. It should look something like this: div class=hentry … div class=author vcard span class=agent vcard a class=fn url href=#Ben Ward/a /span span class=agent vcard a class=fn url href=#Cyril Doussin/a /span (span class=orgYahoo!/span) /div … /div My understanding is that both named people should be ‘agents’ of the organisation. As to how this parses… that could be more fun and needs input from parser developers when they get a moment! Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] jCard draft
On 4 Apr 2008, at 01:23, Gordon Oheim wrote: I have added a preliminary draft for a possible jCard specification to the wiki at http://microformats.org/wiki/jcard. The content is based on what I read from the discussion list so far. The intention was to have a reference for further discussion and for solidifying a candidate for a jCard standard. Hi, This is great work, and it's something that I found a number of developers asking about during South By South West. I think it was Glenn Jones suggesting that we're now at a point with parser maturity that some thought needs to be given to having interoperable JSON structures. I have two points of initial followup, one with my admin hat on, the other without. 1. ADMIN: This discussion should probably take place on the microformats-dev mailing list, rather than -discuss. It should come to the attention of all parser developers that way, and hopefully stay focused on this very parser-centric work. I've cross posted this thread to [EMAIL PROTECTED]; please continue the development discussion there. 2. In my view: I'm totally supportive and in favour of this work, I think ‘jCard’ is a bad name for it; I think this work would be better presented connected to the hCard specification itself — and future equivalents for the other microformats too. Whether that end up as an ‘Object Model’ section of the relevant specs, or new documents (e.g. hcard-object-model). It doesn't need it's own, separate format name; it's really further specifying hcard itself. What's more, whilst JSON is the obvious driver technology for this work, I think it would make more sense to produce an implementation- agnostic Object Model that would work in JSON, XML, YML or whatever other transport people might want to implement for. I think it's unlikely we'd want to specify ‘jCard’, ‘xCard’, ‘yCard’ and so on…) Please forgive my poor wiki editing skills and feel free to add to the page. The page is off to a great start! Keep it up. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Reviving ‘This Week in M icroformats’
On 1 Apr 2008, at 11:05, David Janes wrote: I tried to do my bit! 2008/4/1 Toby A Inkster [EMAIL PROTECTED]: Ben Ward wrote: Each week a new Wiki page will be created to live-edit the 'This Week…' post, and everyone is invited to contribute to it. Has this died out already? Argh, sorry! This has been posted now, combined together from the previous two drafts. THANK YOU to everyone who's been putting effort into keeping the drafts alive. I've created a new draft page for next weeks entry at http:// microformats.org/wiki/this-week-2008-03-31 B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How to avoid building erroneous social network graphs?
On 26 Mar 2008, at 19:32, Costello, Roger L. wrote: pHi Alice. Nice page. I would like to introduce you to my friend a href=Sally.html rel=friendSally/a some time./p Notice the use of XFN: rel=friend When a robot application encounters Alice's web page it will see the representative hCard for Alice and it will see the XFN-bearing link. Here's the relationship that the robot constructs: Alice is friends with Sally But that's completely wrong. Bob stated the relationship. The correct relationship is: Bob is friends with Sally How would a robot avoid this error? The situation you describe there is a publishing problem. If you're graphing social relationships, then the page you're describing has been linked to with rel=me, even though the content of the page is authored by multiple people. A page where other authors can add rel links is unsuitable for use as rel=me node — except where the content management system disallows the rel/rev attribute, or XFN values thereof. There's no way for a robot to avoid that parsing error. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How to avoid building erroneous social network graphs?
On 27 Mar 2008, at 01:02, Charles Iliya Krempeaux wrote: What if you put comments into a blockquote or a q. You could consider XFN in a blockquote or q to be of the person being quoted. That might be a valid parsing rule, I'm unsure. Regardless, it's inappropriate for comments. A comment is a piece of original content on the page, not a quote from another source. It would be appropriate for Trackback or Pingback excerpts, though. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] article on microformats
Hi Igor, On 16 Mar 2008, at 06:43, Igor Wawrzyniak wrote: 1) In my article I wrote that the community behind microformats began as a sort of grasroots movement, involving enthusiasts: bloggers, wikipedia editors, people who were into social-networking sites and other web 2.0 ideas etc. Only later it gained support of software companies and standarization bodies. Do you agree with that summary? Remember I need to keep it short, it's only an introduction, I'm mostly writing about technology. Best to have Tantek, Eric or one of the other Technorati alumni answer that, since they were here in the very beginning. I think it would be inaccurate to say that it has the support of ‘standardisation bodies’. The microformats are designed and built within this community, and don't get rubber stamped by any other body. The existence of microformats is acknowledged elsewhere, of course, and the spread of hCalendar is probably a principal factor in HTML5 having a new time element. 3) On a more technical note. I'm confused about a rel-tag. Let's say I run a website that has it's internal tagging system, each post is concluded with a few links: this article belongs to category this, that and yet another. I can also ocassionally link to an external site that supports tagging, like del.icio.us. Do i include a rel-tag on: - internal links - external links - both? Where you are linking from your content (say a blog post) to a tag space (whether that's Technorati or your own site), you should use rel-tag to indicate that the two pages have a tag relationship. FAQ says I'm not supposed to use rel-tag on links in a tag-cloud, why? Where you use the ‘rel’ attribute, you are saying ‘The page I'm linking to is a something for this page’. So in a blog entry, rel=tag means ‘The ‘/tags/microformats’ page I'm linking to is a TAG for this page’. It's a more subtle meaning than ‘this _is_ a tag’. A tag _cloud_ is an aggregation of tags for multiple pieces of content. If you put rel=tag on the tags in a tag cloud, you would be saying ‘this is a tag _for the current page_’, which is not what a tag cloud represents. Hope that helps, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Unjust banning of Andy Mabbett
On 15 Mar 2008, at 22:09, Jesse Rodgers [EMAIL PROTECTED] wrote: There is a risk that without the formality, leadership, andstrength then why doesn't IE8 rename things and add a little bit here and there? How about Google? They may want their own gCal format because hCal is just a hobby. Does the microformats community require formality in order to retain consistency in those that think they know better? The fact that we are not a formal standards body doesn't seem to be causing an issue. In fact, Microsoft have been extremely positive in their recent hSlice communications: Not misusing the word 'microformat', not breaking hAtom. Everything they did in speccing their own pattern was correct and played-nice with our existing community driven microformats. Similarly, Yahoo's recent communications regarding search enhancements (which use microformats, RDFa and eRDF) draw a clear distinction between the different technologies. To me, it reflects that whilst we ended up in this community-driven, dictatorless body somewhat by evolution, it does work well enough. It's important to remember that the technologies we build on — HTML and the @class and @rel attributes it provides — are not controlled by us. We are perhaps the largest organised use of @class, but we have no exclusive claim to the attribute. As such, microformats.org as an organisation has to respect others creating patterns in their own way too. If Google wanted gCal, or Yahoo wanted yWidget or something, they're entitled to it. I think the best way to interact in such an open space is as a community. I think too much formal process, elections, etc get you into an issue where 'he/she with the most time wins' as with any volunteer organization. Completely agreed, it increases the amount of the time the community has to spend on meta-issues. Even in the past 10 days, only a small minority of people have shown an inclination to engage in this meta- discussion. Administration of the community shouldn't interfere so much as to be a constant concern. But, when the community aesthetic isn't conductive to productively working on the microformats themselves, something is astray and where it requires intervention we will do our best to correct it. There is a risk that this could all be replaced and all that work forgotten... details of this thread aside, perhaps a little benevolent leadership is required to direct the community? So long as the output of this community is of high quality, the formats we product will hold authority on the web. I don't currently believe that creating formats with high authority must be created in a highly authoritative environment, though. They're separate issues, and if the format is high quality, the process in which it is built is irrelevant. Cheers, B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Reviving ‘This Week in Microform ats’
Something we're keen to try and do is improve the way microformats — and especially progress on microformats — is communicated outside of the microformats community. I had a brief shot of it a little over a year ago with the ‘This Week in Microformats’ posts to the blog. The reason they died out is because they tended to require long editing stints to produce something of the quality I wanted. A few weeks of being too busy and the idea collapsed. We're going to bring the weekly posts back, but rather than it being my own little initiative it's now properly integrated into our community tools. Each week a new Wiki page will be created to live-edit the ‘This Week…’ post, and everyone is invited to contribute to it. The headings are set out, so it should be intuitive to contribute items. We're going to follow the same tone and format as the original posts, and post them every Sunday evening (GMT, most likely), so it's there and fresh for Monday morning. If you can write with the same voice that will make editing much easier, but either way it should make it all much easier to compile. The live draft for this week's post is on the wiki now: http:// microformats.org/wiki/ThisWeek/2008-03-10 Thanks, B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Include Pattern Update
Hey everyone, Following the research we did at Yahoo! last month, I've updated the include-pattern documentation to clarify, based on evidence, the accessibility issues raised. I've been through the documentation in full, and the following summarises the changes for those not wishing to analyse the Wiki diff. http://microformats.org/wiki/include-pattern • Restored requirement for the hyperlink include pattern to include inner-text • Changed the hyperlink pattern example to use hReview, not hResume, as the requirement for inner-text is not compatible with the needs of hResume. • Added clear accessibility guidance to the hyperlink include pattern • Clarified the language around use of CSS to improve the user experience around the include pattern, to make it clearer they are enhancements. This is a mark-up spec, and cannot depend on CSS. • Directed scenarios that require content-less includes to the OBJECT pattern • Removed statements of opinion and discussion. This is supposed to be documentation for the pattern, it should be concise and precise and should not contain tangential remarks. In future, areas of uncertainty should be documented only on the -issues or -feedback page (http://microformats.org/wiki/include-pattern-issues and http:// microformats.org/wiki/include-pattern-feedback repsectively). It's really, really, important that the documentation remains clear. • Updated the ‘Thanks’ section to acknowledge the work my co-worker Mike Davies did in researching empty-hyperlink accessibility. • Added explicit point that other microformat class names on the include element are discarded, and that all microformat classes should be on the target of an include, not the include element itself. Closes Mike Kaply's open issue. Please not that this update does not in any way concern of reflect recent discussions about specifying another include pattern (http:// microformats.org/wiki/include-pattern-strawman). This just brings us up-to-date with current research and knowledge. Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Dublin Core as a microformat (was: Re: xfn and biographies)
I wonder if this use case is already solved by eRDF, since that provides mechanisms for linking to the Dublin Core namespaces and then specifying the properties in HTML class attributes. On 30 Jan 2008, at 20:20, Andy Mabbett wrote: span class=DC.publisherAcme Inc./span or, inside another microformat, say hCard: span class=DC.publisher fn orgAcme Inc./span In eRDF, that becomes: span class=DC-publisherAcme Inc./span and span class=DC-publisher fn orgAcme Inc./span respectively. The only practical difference I see, were we to approach this in the microformats process, is that we'd find a different solution to including links to RDF schema in the HEAD of a document (in eRDF, using link rel=schema). Is that the only problem we'd be trying to solve in making a Dublin Core microformat? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Hyperlink Include Pattern Research
Last year I found some time to edit the include-pattern pages on the wiki in response to serious implementation issues surrounding the use of OBJECT to reference other parts of the page (aside: It causes multiple HTTP requests to same URL in some browsers and nearly blocked the inclusion of microformats in one of our sites). One of the key edits was to move the hyperlink-based alternative include pattern above OBJECT, and recommend it in its place. At the time of my original edit, I ensured that all hyperlink examples included inner-text to best support accessibility, according to my understanding of hyperlink issues at the time. Since then it was raised that hResume actually required that _no_ inner text be present (regardless of the include technique used) as it was only used to include a single piece of information (the hcard fn property). This resulted in an edit — still present in the current page — that recommends a hyperlink with no inner text, but including a title attribute in its place. The whole development has become fuzzy and lacks evidence to support mark-up decisions either for or against support of certain accessibility techniques. The issue has been short on solid research, so thanks to the commitment and incredibly dedicated work of Mike Davies, my co-worker at Yahoo! in London, we now have some. Mike has organised a test of hyperlinks in multiple configurations and had them tested by real users of screen readers (Artur Ortega and Victor Tsaran of the Yahoo! Accessibility Stakeholders Group). There's no simulation, or guesswork. Both testers depend on screen reader technology every day. With their co-operation, we hope to have produced the most useful and insightful test data on hyperlinks, and identify the most probably behaviour of most screen readers in the wild. Mike has provided a thorough write up of his research on the Yahoo! User Interface Blog: http://yuiblog.com/blog/2008/01/23/empty-links/ I encourage you to take a little time to digest it, and note the complex caveats that screen readers introduce to our work. The conclusions are drawn clearly, and there's plenty of reference to our include-pattern development. I need to do another pass over the include-pattern page, tidy it up again and move discussion onto the -issues page (I didn't have a chance to update the issues page when I updated the spec, so I'll do that this time around). I'll be taking some time to digest this research first, and work to present the pros/cons of our current solutions as best we can. In doing so, I'll try to identify if there are situations which neither pattern can solve. Your feedback is encouraged, and we hope this research proves useful to the community (and beyond). Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Largest Deployment of Microformats on one site?
For reasons which will be revealed next week (yes, I'm a tease, sorry), I'm interested to know what the largest deployment of any microformat is on a single site, in terms of numbers of instances of microformats. Does anybody know? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Event: SemanticCamp London Feb 16-17
On 9 Jan 2008, at 10:44, Tom Morris wrote: Would love to see some fellow microformateers there! The signup form even lets you import your details from hCard or FOAF, so there's no excuse...! Oh lovely, although the post-parse form doesn't handle having found multiple URLs in an hCard. Perhaps a drop down list to pick one of many where multiples are found? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
On 16 Dec 2007, at 20:09, Manu Sporny wrote: It is important for us to focus on the reason this discussion started in the first place: http://microformats.org/discuss/mail/microformats-discuss/2007- December/011035.html The issue was accessibility, specifically, how accessible is the ABBR design pattern for those that use screen readers. No, Manu, that was not the reason this most recent discussion started. In fact, the catalyst for this most recent iteration concerns not accessibility — I deliberately avoided that as finding precise data is too difficult. The issue at hand is that more recent specifications such as GEO (albeit brainstorming) and hAudio are mandating the use of the ABBR pattern in a way which is not compatible with the HTML specification. Yes, there are many here who care a great deal about the implications of microformats on users of assistive technology, but it is clear that most contributions here are unable to find sources or recorded evidence to support or refute any claim. Unfortunately, gaining such evidence from people who really use AT daily is neither easy nor inexpensive. You or I downloading a trial of JAWS and running it will not useful test results. This is not true. You can set several, of not all, screen readers to not read titles of SPAN elements. The issue is not whether you _can_ set a screen reader to read or ignore @title attributes, it is whether users actually do or not. The limited experience I have from inside Yahoo!, where I have been able to ask some very generous people to assist in accessibility testing on another issue, is that people who depend upon AT tools are far more inclined to customise their tool to improve their experience. As such, there are a plethora of combinations of tools and configurations consuming pages. One can presume on the basis that these users are more inclined to configure their tool, that such a user will configure their tool optimally for their usage, depending on the kind of content they interact with the most. As such, we cannot ever work on the basis that upon discovering machine data in the @title attribute of a microformat property that they will simply reconfigure their tool; their choice to enable reading of titles will be useful for some kinds of content. It is the quantity of variables in the field of AT and the expense of testing them which makes it hard for a community of our limited resources to make decisions based on AT performance. But whether criticising or supporting a pattern, vague statements about the behaviour of AT help nobody. I think this discussion would progress better if people stay focused on the data requirement and the semantics of the output first, and the implementation second. So far, we're getting very sidetracked by a series of new proposed hacks, rather than identification of which problems need solving by a precision/expansion pattern. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [ADMIN] Split Thread: Precise Expansion Patterns
Hi, The current ‘Precise Expansion Patterns’ thread is now spreading into multiple discussions, and also discussions which in fact should not be on the uf-discuss list. Please continue discussion concerning identification of the places where microformats require a precision/expansion pattern, and the semantics of that pattern in the current ‘Precise Expansion Patterns’ thread. Please move discussion concerning the development of hAudio onto the microformats-new discussion list, as it has ceased to be concerned with the use of a pattern, and has moved onto the data format of hAudio itself. Thank you, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
On 17 Dec 2007, at 00:31, Jeremy Keith wrote: Andy wrote: Span is used as an example of a generic paired element. Good. That's what I was hoping. Then can we say that instead of saying SPAN? Please? :-) Perhaps adopt a convention of using FOO or a more English friendly ANYELEMENT ‘element’ when writing such examples in this discussion? I think it might assist the wider thought process and keep people thinking generically, rather in terms of SPAN. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)
On 14 Dec 2007, at 14:06, Benjamin Hawkes-Lewis wrote: I think all of the following would be misuses of ABBR and TITLE: | Combien d'œufs ai-je vendre? J'ai vendu abbr title=quarante-cinq | 45/abbr aujourd'hui. | Combien d'œufs ai-je vendre? J'ai vendu abbr title=45 | œufs45/abbr aujourd'hui. | Combien d'œufs ai-je vendre? J'ai vendu abbr title=45 | eggs45/abbr aujourd'hui. | Combien d'œufs ai-je vendre? J'ai vendu abbr title=30+15 | 45/abbr aujourd'hui. | Combien d'œufs ai-je vendre? J'ai vendu abbr | title=sales:a464Z37;q45dt200712200745/abbr | aujourd'hui. 16:03 could be re-expressed as 3 minutes past 4pm. It's not obvious that 16:03 is an /abbreviation/ of 3 minutes past 4pm. For one thing, the 12-hour clock is not an expansion of the 24-hour clock: they are equivalents. For another thing, I'd say it's more of a common symbolic representation. 4 wouldn't normally be called an abbreviation of four: it's just a symbol. (Some symbols are also arguably abbreviations, at least in origin, like cm, but this wouldn't generally be said of 4.) Agreed. I'll repost something I put into the GEO thread last week. It's quoting directly from the HTML4 specification. This doesn't actually need to have any concern with accessibility, or assistive technology tools. Frankly, the difficulty in getting solid tests from such tools makes that line of argument less attractive in itself. But what has to be a fundamental baseline in our implementation of optimisation patterns in microformats is the HTML specification we are building on top of. We *do not* have the authority to disobey the spec. We may interpret it _more strictly_ perhaps, but we may not _relax_ any of the definitions it provides. Otherwise we have no leg to stand on regarding the effect our code has on _any_ consuming tool. I said this: “The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.” For emphasis again: “as it would normally appear in running text.” I know there are lots of concerns about the effect of the ABBR pattern on assistive technology tools. I know there are reports of problems and negative impact on user experience. Getting evidence is proving hard because the sheer number of variables in a real assistive technology user's configuration is much larger than for visual desktop browsers. It actually doesn't matter, because the ABBR pattern is being mis-used at a more fundamental level. First, some happy news. Here's the ABBR pattern being used validly and correctly in hCard: abbr class=country title=United KingdomUK/abbr There is an argument that the ISO timestamp format is an expansion of a human formatted date (‘Thursday, September 23rd’). I personally disagree, but it was accepted at the time. But since then, the use of the pattern has expanded without the same concern for the HTML spec. ‘One hour ago’ is NOT ever an abbreviation of a timestamp. ‘last week’ IS NOT an abbreviation of a timestamp. ‘London’ IS NOT an abbreviation of a set of co-ordinates and ‘3:23’ IS NOT an abbreviation of the string ‘PT3M23S’ (hAudio). In all of those cases they are ‘alternative representations’, or ‘expansions’ or perhaps ‘precisions’. They ARE NOT abbreviations and they are in clear conflict with the HTML spec which states the TITLE attribute of ABBR must be ‘the abbreviated expression itself, as it would normally appear in running text’. Sorry, but the ball got dropped on this, and people have been treating the ABBR-pattern as a handy pattern first and HTML second. That is the wrong way around. So we have a problem. We now have multiple use cases where it is necessary for publishers to include precise machine data alongside human legible descriptions. They are rarely real abbreviations. I am going to ask that we better define the problem. That we follow up the demand for a better pattern (regardless of whether your personal motivation is following the spec or assistive technology). I'd like to ask that people stop jumping straight in with ideas for alternative mark-up, ways of kludging the existing practice into different elements or attributes. Follow the process. We need to fully define the problem: We need a list of which microformat properties _require_ the facility for precise representations. They don't all need it, maybe we just need something that certain properties may opt into, rather than something that covers all microformats properties. That's what we need to determine. From there, we can move on how to integrate the data back into mark-up. Thank you, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org
Re: [uf-discuss] Re: ‘XHTML’ references to ‘HTML’
Got around to making some of these changes today. Actually not as many as I'd expected to. The pages with slightly tweaked references to ‘HTML or XHTML’ are: [[hcalendar]] M http://microformats.org/wiki? title=hcalendardiff=0oldid=23673 * BenWard * (+5) Making consistant references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread last week. [[hcard]] M http://microformats.org/wiki? title=hcarddiff=0oldid=23675 * BenWard * (-3) Making consistant references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread last week. [[rel-license]] M http://microformats.org/wiki?title=rel- licensediff=0oldid=23676 * BenWard * (+6) Making consistent references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread 2007-11-26 [[geo]] M http://microformats.org/wiki?title=geodiff=0oldid=23677 * BenWard * (+5) Making consistent references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread 2007-11-26 [[xfolk]] M http://microformats.org/wiki? title=xfolkdiff=0oldid=23678 * BenWard * (-1) Making consistent references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread 2007-11-26 [[adr]] M http://microformats.org/wiki?title=adrdiff=0oldid=23679 * BenWard * (+3) Making consistent references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread 2007-11-26 [[hreview]] M http://microformats.org/wiki? title=hreviewdiff=0oldid=23680 * BenWard * (-10) Making consistent references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread 2007-11-26 [[hresume]] M http://microformats.org/wiki? title=hresumediff=0oldid=23681 * BenWard * (+4) Making consistent references to ‘XHTML’ and ‘HTML’ as per uf-discuss thread 2007-11-26 As per the discussion last week, in the first instance these pages now refer to both ‘HTML’ and ‘XHTML’ explicitly, and later references are just ‘HTML’. The exception to this at the moment is the XOXO spec, which has been written in a very XHTML-centric way from the outset, and may need to be reviewed in relation to how it is actually being published on the web (to see whether we need to accommodate a reality of publishers putting XOXO in HTML documents, not just XHTML). I've also not yet update the ‘XHTML Design Principals’ template which recurs in most of the above pages. Again, that's a very XHTML centric passage which doesn't accommodate HTML so cleanly and can't be tweaked with find and replace. Any suggestions on changes to those passages are appreciated. Regards, Ben On 27 Nov 2007, at 10:01, Ben Ward wrote: Right, I'll put this on my to-do list. I don't know how much work it's going to be yet, but let's say I'll plan to start updating pages on Friday. That's the rest of the week for anyone else to object to the change. The change I propose is: • Update the first mention of ‘HTML’ or ‘XHTML’ (or variant) in a page to ‘HTML and XHTML’ • Update other references to XHTML, (X)HTML or X/HTML to ‘HTML’ Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Avoiding Premature Optimisation in ‘The Process’
As some of my recent messages will clearly suggest, I'm concerned that we are becoming too quick during development of new formats to leap on some of the optimisation patterns established for other formats (abbr-pattern, include-pattern). We're starting to see situations — such as co-ordinates being the expansion of a place name — where we seem to be thinking of the pattern before we're thinking about the meaning of the raw HTML it produces. I'd like to see the Process include something that perhaps discourages or even disallows the use of optimisation patterns (Include, ABBR, any others in the future) until after the first sets of mark-up are produced and semantically optimised. Then, where patterns do match the optimal mark-up and HTML semantics, they can be added. Where they do not, then we identify situations that require new patterns. My hope would be that by including such a step, we avoid shoehorning things into the ABBR pattern that are inappropriate, and force the entire development community to think about HTML first. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar, geo Operator extension
No immediate theories on your parsing problem I'm afraid, although I would flag this as an issue: On 3 Dec 2007, at 16:34, Premasagar Rose wrote: abbr class=geo point-20 title=+22.31119; +89.86145 Rayenda, Bangladesh /abbr There's no way that ‘+22.31119;+89.86145’ is an abbreviation of ‘Rayenda, Bangladesh’. Please, don't neglect the defined semantics of HTML in order to hack parsers. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar, geo Operator extension
On 3 Dec 2007, at 18:58, Scott Reynen wrote: On Dec 3, 2007, at 11:18 AM, Ben Ward wrote: abbr class=geo point-20 title=+22.31119; +89.86145 Rayenda, Bangladesh /abbr There's no way that ‘+22.31119;+89.86145’ is an abbreviation of ‘Rayenda, Bangladesh’. Without commenting on the truthfulness of the statement, the above syntax says the opposite: that Rayenda, Bangladesh is an abbreviation of +22.31119;+89.86145. The title attribute is the long form, not the abbreviation. I don't know if this is just careless language or actual confusion, but this has come up multiple times and I think it's important we're all clear on what the markup asserts if we're going to have a discussion about the truthfulness of that assertion. You are completely correct, not a misunderstanding on my part, I just wrote the wrong thing (I've been rather ill, my brain isn't joining all the dots in the right order at this point). I stand by point, and I think the examples on geo-brainstorming are dangerous. Premasagar, the ‘brainstorming’ pages are just that, and shouldn't be considered part of the specification itself. I'm sorry that our pages are misleading like that. The critical part of the HTML4 spec that causes ‘Rayenda, Bangladesh’ *not* to be an abbreviation of ‘22.31119;+89.86145’ is this: “The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.” “as it would normally appear in running text.” Whilst I appreciate the HTML4 spec can be a little vague sometimes, in this case it's pretty clear: ABBR is not for fuzzy approximations, it's for abbreviated expressions. I think we've got to be really delicate and careful about this. Microformats prides itself on building technologies on top of existing standards. The abbreviation pattern is a neat parsing trick, but you've gotta meet the requirements of the underlying technology. Regards, Ben For reference, the section from the HTML4 spec regarding ABBR and ACRONYM ABBR: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.). ACRONYM: Indicates an acronym (e.g., WAC, radar, etc.). The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. Western languages make extensive use of acronyms such as GmbH, NATO, and F.B.I., as well as abbreviations like M., Inc., et al., etc.. Both Chinese and Japanese use analogous abbreviation mechanisms, wherein a long name is referred to subsequently with a subset of the Han characters from the original occurrence. Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers. The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. Here are some sample uses of ABBR: P ABBR title=World Wide WebWWW/ABBR ABBR lang=fr title=Socieacute;teacute; Nationale des Chemins de Fer SNCF /ABBR ABBR lang=es title=Dontilde;aDontilde;a/ABBR ABBR title=Abbreviationabbr./ABBR Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while IRS and BBC are typically pronounced letter by letter, NATO and UNESCO are pronounced phonetically. Still other abbreviated forms (e.g., URI and SQL) are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form. — http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: ‘XHTML’ references to ‘HTML’
Right, I'll put this on my to-do list. I don't know how much work it's going to be yet, but let's say I'll plan to start updating pages on Friday. That's the rest of the week for anyone else to object to the change. The change I propose is: • Update the first mention of ‘HTML’ or ‘XHTML’ (or variant) in a page to ‘HTML and XHTML’ • Update other references to XHTML, (X)HTML or X/HTML to ‘HTML’ Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] using microschema
On 26 Nov 2007, at 13:07, Tatsuya Noyori wrote: Is this correct? a style=visibility:hidden rel=microschema href=http://microformats.org/2007/hcard.rng;hcard microschema/a That would be valid, but of course you now have unwelcome content added to the page. I urge you to step back, take in the responses already made elsewhere in the thread (particularly regarding HTML profiles). You need to have a problem to solve before you focus on some sort of solution. You've still not described a problem that this would solve. If there's a problem with the way microformats are currently implemented then we absolutely need to know about it, but so far the namespaceless, schemaless system we're using seems to be working out fine. But if that's not the case, please highlight the problem. Additionally, and I mean this more generally, everyone proposing anything into syntax must remember that microformats operate in HTML, not just XHTML. Any solution dependent on XML, such as self-closing elements which are not self-closing in HTML4, is not appropriate for microformats. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] ‘XHTML’ references to ‘HTML ’
Since microformats are published in both HTML and XHTML, I think we need to tidy up our references on the Wiki. Again this week we've had an — admittedly premature — suggestion of new syntax which is XHTML only (a /). That proposal has a few problems as have been discussed, but I think we should fix the Wiki to not give the wrong impression about our use of XHTML in the first place. This is not about ‘XHTML vs. HTML’. I don't care which you prefer to use. This is about making clear that microformats are an HTML technology, not an exclusively XHTML technology. ‘HTML’ implies compatibility with XHTML, ‘XHTML’ does not imply compatibility with HTML. I'd like us to update the wiki to make all references to ‘XHTML’ and ‘X/HTML’ or ‘(X)HTML’ into clear ‘HTML’. Again, ‘HTML’ implies ‘XHTML’, so there's no need to use clumsy amalgamations in regular text. The first mention of HTML on the Wiki front-page should be updated to make clear that ‘When we say HTML we refer to both HTML and XHTML syntaxes’. For all intents and purposes in microformat development and publication, there is no difference. Does this seem worthwhile? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ‘XHTML’ references to ‘H TML’
On 26 Nov 2007, at 15:55, Ciaran McNulty wrote: Is (X)HTML too unwieldy to be the global replacement? I feel that ‘(X)HTML’ or ‘X/HTML’ in every instance would read clumsily and uglify the text. It would be irritating to read an entire document where every instance of a familiar and legible abbreviation was peppered with parenthesis. I proposed having a single ‘HTML and XHTML’ definition on the microformats wiki front page, but it would be reasonable to say that the _first_ mention of HTML on every wiki page should say ‘HTML and XHTML’ or ‘HTML or XHTML’ as appropriate. Having the first instance expanded is good practice for abbreviations, so it would make sense to expand the first ‘HTML and XHTML’ and use ‘HTML’ thereafter. How's that? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ‘XHTML’ references to ‘H TML’
On 26 Nov 2007, at 16:02, Brian Suda wrote: 2007/11/26, Ben Ward [EMAIL PROTECTED]: This is about making clear that microformats are an HTML technology, not an exclusively XHTML technology. 'HTML' implies compatibility with XHTML, 'XHTML' does not imply compatibility with HTML. --- i'm not sure HTML does imply compatibility with XHTML. HTML you can be sloppy and not close tags, that is not XHTML compatible. Then HTML5 is not following the SGML rules, so somethings in HTML5 will NOT be valid XHTML no matter how you slice it. (but that is off topic for this thread) I mean that in the context of using the microformats syntax, not of the HTML itself. In terms that XHTML is a stricter syntax of HTML, therefore HTML is the lower common denominator than XHTML. You can use the same microformats syntax within either the liberal parsing rules of HTML or the strict rules of XHTML. Referring to HTML in place of ‘HTML or XHTML’ does not imply anything about a publisher's usage of HTML. If they are using XHTML then they will understand the addition syntax rules that must be adhered to. However, referring to XHTML where we mean ‘HTML or XHTML’ implies that the publisher _must_ adhere to the stricter rules, or implies to a parser that it can depend on them. André Luís: I agree with the concern. I sat on a presentation where the speaker spoke of microformats as if they were xhtml-only. I know the POSH concept is there to prevent this confusion, but apparently, it's not enough, Is it? Maybe POS(X)H doesn't seem to cut it, does it? I'm not sure that ‘POSH’ has made anything less confusing to anyone. As far as communication goes, this is definitely a separate issue. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: ‘XHTML’ references to ‘HTML’
On 26 Nov 2007, at 19:49, Paul Wilkins wrote: On Nov 27, 2007 8:28 AM, Edward O'Connor [EMAIL PROTECTED] wrote: Ben Ward wrote: I'd like us to update the wiki to make all references to 'XHTML' and 'X/HTML' or '(X)HTML' into clear 'HTML'[...] Does this seem worthwhile? I'm all for it. I'd love to take this even further, and s/XHTML/ HTML/ in XMDP and XFN, but those ships have sailed. The only concern that I'd have is that visitors to the site are likely to think that microformats are an older less worthwhile idea because of all the HTML references. First impressions can be important, so how can that be dealt with? By mentioning ‘XHTML and HTML’ in each first instance, we make clear that both flavours are compatible, whilst using ‘HTML’ there on reads as a cleaner abbreviation. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: ‘XHTML’ references to ‘HTML’
On 26 Nov 2007, at 21:21, André Luís wrote: Here's an idea... since that would involve altering every page with xhtml in them anyway, why not go one step further and in the first reference to XHTML change it to HTML or XHTML with a link to an explanatory page? Stating that ufs work on both worlds. We could, but does it need greater explanation than ‘HTML or XHTML’. What more is there to say? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] using microschema
On 25 Nov 2007, at 11:34, Philip Tellis wrote: On 25/11/2007, Tatsuya Noyori [EMAIL PROTECTED] wrote: I changed link to a. Is this correct? AFAIK, a tags need some text inside. Well, to be valid an Anchor needs to be explicitly closed, since self- closing cannot be used in HTML. Inner text _can_ be omitted, but until we've got some more feedback on the assistive technology implications I'd consider it ill advisable. And yes, such feedback is in the works following the include-pattern update. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] OBJECT Pattern Page Updated
Hi everyone, Following on somewhat from the messages last month regarding the OBJECT pattern I've updated the Wiki page (http://microformats.org/ wiki/include-pattern) quite substantially. The old page was a mess, especially with the later addition of the hyperlink include pattern. I've reorganised it to give both patterns equal substance on the page and following the most recent, serious OBJECT pattern issues I've moved the Hyperlink pattern above the OBJECT pattern in the Wiki page. • I've made the examples for both patterns consistent: They use the same scenario now, the only difference being the use of A or OBJECT. I hop that will make it easier to follow and compare. I've also made the pitfalls for each pattern clear below each. • Much of the text has been edited for what I hope is more clarity. The voice (‘you can…’) has been neutered. q • The hyperlink pattern now acknowledges the assistive technology implications and actively encourages inclusion of inner text in hyperlinks. • This update also makes the ‘replacement’ behaviour of the object pattern clearer, which I hope addresses the issue raised on the Wiki by Mike Kaply (regarding how to parse the pattern). • Much emphasis is put on the scope of the include pattern being same- page. This is a big edit, but the page was not in a good state and this needed doing. I ask that people take a little time to read the new version, compare it to the old and raise any remaining issues. Thank you, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] OBJECT Pattern Page Updated
Hi everyone, Following on somewhat from the messages last month regarding the OBJECT pattern I've updated the Wiki page (http://microformats.org/ wiki/include-pattern) quite substantially. The old page was a mess, especially with the later addition of the hyperlink include pattern. I've reorganised it to give both patterns equal substance on the page and following the most recent, serious OBJECT pattern issues I've moved the Hyperlink pattern above the OBJECT pattern in the Wiki page. • I've made the examples for both patterns consistent: They use the same scenario now, the only difference being the use of A or OBJECT. I hop that will make it easier to follow and compare. I've also made the pitfalls for each pattern clear below each. • Much of the text has been edited for what I hope is more clarity. The voice (‘you can…’) has been neutered. q • The hyperlink pattern now acknowledges the assistive technology implications and actively encourages inclusion of inner text in hyperlinks. • This update also makes the ‘replacement’ behaviour of the object pattern clearer, which I hope addresses the issue raised on the Wiki by Mike Kaply (regarding how to parse the pattern). • Much emphasis is put on the scope of the include pattern being same- page. This is a big edit, but the page was not in a good state and this needed doing. I ask that people take a little time to read the new version, compare it to the old and raise any remaining issues. Thank you, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How to handle empty lists ?
On 30 Oct 2007, at 17:09, [EMAIL PROTECTED] wrote: I'm new to microformats. Welcome! I'm trying to use microformat style xhtml to represent some data. OK. Howeber, what you're using is really semantic HTML, it's precisely what the class attribute was designed for. Call it a pattern or a data format as you like, but keep in mind that ‘microformats’ are a process by which formats are defined, not a syntax in itself. The syntax you're using is just HTML. Somme data are lists of items represented by an ul element. XHTML (HTML) do not allow empty lists, but my data model uses empty lists. How to deal with this : - use an empty span class=empty-list element, - use a fake element ulli class=ignore //ul, - use empty list and ignore xhtml rule, - ... ? To be pedantic, is an empty list really a list if it doesn't list anything? For whatever pattern you are designing, why not just define a parsing rule based on the absence of the list? If the list is present, then you know that there is data, if it is absent then you know there is not. Regardless of validation, including an empty list in an HTML document is poor code really. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How to handle empty lists ?
On 30 Oct 2007, at 18:03, Phillip Hofmeyr wrote: Is this the XOXO format? Can anyone send me some urls for sites that use XOXO? We've marked up the new category trees and sitemaps on Kelkoo using XOXO: • http://www.kelkoo.co.uk/sm_site-map.html Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Cross-Page Includes (was: OBJECT include pattern and excess HTTP requests)
In the interests of tidy administration, I'm splitting this thread. The originally raised and the proposal for including remote content within microformats are very different issues and it's important that the original thread stay on track. Thanks. On 10 Oct 2007, at 02:59, Michael MD wrote: PS It's then just a small step to allow off-page includes, which is related to the interlinked hCards on different sites that I was talking about recently on this list. If anyone can come up with more real-world use-cases for this type of cross-site uF linkage, I'd be most grateful. Looking further ahead (wrong list for that, I know) I'd see good mashup opportunities from allowing more uF interlinkage...=0) interesting ... but the extra complexity that would add to parsers (requiring them to do the extra requests) would be a problem.. also what about pages being looked at offline? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hreview using include pattern
On 9 Oct 2007, at 00:57, Brian Miller wrote: In looking at the hreview examples (apple, readandtravel) who have a similar structure, they usually repeat the item information in each review and use css to hide it. This seems messy from a semantic and accessibility point of view. Most screenreader users would not enjoy hearing the item information every time. I haven't checked, but they may be slightly older implementations. For a time there was a problem with the OBJECT include pattern in Safari, which led to the Anchor based include pattern being designed. That in turn is sub-optimal as empty-anchors are poor accessibility. So, if those implementations were built before Safari fixed its OBJECT bug — or before that fix was regarded as wide-spread — then they may have compromised with repeating data. The new hReview deployment we've just put out uses the OBJECT pattern. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] OBJECT include pattern and excess HTTP requests
Hey hey, Quick question for people publishing hReview. Long ago when the OBJECT-include pattern was first raised, there was a bug in Safari that made it unworkable. That bug got fixed. However, there appears to be a separate, very serious browser issue whereby browsers are making additional HTTP requests for each OBJECT include in a page, even though the data attribute is making a same- page fragment reference (#review-item or whatever). I've swapped for the hyperlink include pattern (however, repeating the review item name as the InnerText of the anchor, so as not to create poorly accessible empty anchors). What I want to know is if anyone else knows of a robust solution to prevent browsers firing off these extra requests from the presences of OBJECT? My feeling is that the Wiki content on the include pattern needs a tidy anyway, but if this issue with firing unwanted requests is unfixable, I think we should restructure to promote the hyperlink- include as the first-choice solution. I should emphasise that whilst it may be a non-issue or trivial for small-scale publishing, firing off these extra requests is a deal- breaker performance problem on the scale of sites we have at Yahoo. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hreview using include pattern
On 9 Oct 2007, at 18:39, Brian Miller wrote: Great, so I can use the object. So back to the original question: Can the item information be separate from the first review and just included in the first review using object? If yes, then does that item information need to be wrapped in hreview? Yes it can. Our reviews have the ‘item’ part at the top of the page and then the reviews themselves appear further down. Any tools to test and validate? Operator for Firefox has a debug mode that shows the parsed object structure from the page, so you can see that everything is as you expect. One HUGE update to what I've said previously though. I'll quote my other mail to the list from earlier today. In short, we've had a problem with using OBJECT, so switched to the alternative hyperlink include pattern instead (http://microformats.org/wiki/include- pattern#hyperlink_include_example) […] there appears to be a separate, very serious browser issue whereby browsers are making additional HTTP requests for each OBJECT include in a page, even though the data attribute is making a same-page fragment reference (#review-item or whatever). I've swapped for the hyperlink include pattern (repeating the review item name as the InnerText of the anchor, so as not to create poorly accessible empty anchors). Please do note the last point about including inner text in the hyperlink. The wiki is out of data and shows examples with empty A elements. That's bad accessibility practice, and I intend to rectify the examples once I get some consensus from my ‘OBJECT include pattern…’ thread. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [hListing] Listing
Hi, On the subject of reviving µf development, I've been doing a lot of implementation work with the hListing draft and over the next few weeks will be hoping to document what we've been able to do with it. In the follow up to that I'd like to see about moving the draft along, tightening it up and taking a view toward making a release of it. That work will be sent to the microformats-new mailing list as it happens. I know there are some other implementations of hListing already in the wild: EdgeIO, Dealtagger and Emurse acording to the Wiki. Is there anyone from those companies still active here who wants to be involved? So please consider this a heads up for making new progress on Listing and if anyone at all is interested, please take a look through the existing work (http://microformats.org/wiki/listing) and post and thoughts to Microformats-New. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Correct way to use the key property of hCard
I don't know the answer to this particular problem, but: On 17 Sep 2007, at 22:23, Scott Reynen wrote: abbr class=type title=PGPpublic key/abbr ‘PGP’ is not an abbreviation of ‘public key’. Assuming the rest of the example is correct, you'd need to do something like: span class=key span class=typePGP/span Public Key: span class=valueBlah/span /span Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Need for plain-language intros for each microformat
On 5 Sep 2007, at 20:18, Toby A Inkster wrote: Syntactically the URI would still work, however, semantically it would have been broken, that is, it is bad to not only change URIs so that they 404 and just plain don't work, but it is also bad to change the *meaning* of that URI. As long as there is a clear link to the specification from the explanation, then I disagree that it's really changed the meaning of the link target. Whilst the ‘meaning’ in terms of microformats.org/wiki/hcard being a page about hCard would still be valid, the context in which that URL is used by publishers on the internet. Tutorials may link to the entire page accompanied by the text ‘read the hCard specification’, whilst other pieces could be linking to fragment identifiers within the page to reference a specific part of the spec. As such, I also oppose that the specifications be moved from the current root locations. Potentially we could agree that future specifications include ‘-spec’ in the URL, but current URLs and content IDs need to remain the same. I would move that plain text ‘-info’ pieces be written for each spec and an introductory paragraph from each be placed at the top of each spec to more accessibly introduce the document, with a link to the ‘All about hCard’ page. Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard multiple locations
On 27 Aug 2007, at 14:54, Jason Karns wrote: Although not relevant to the discussion, I believe I will continue to mark up each physical address with its own GEO and let the parsers extract what they will. Unless, of course, a more appealing solution or convincing argument is proposed. This is possibly an application of the VCARD AGENT property? http://www.ietf.org/rfc/rfc2426.txt (§3.5.4 AGENT Type Definition), and the VCARD-RDF implementation at: http://www.w3.org/TR/vcard-rdf (§3.6 Agent property). This describes vcards within vcards, such as for employees of an organisation. However, it has never been put into practice in hCard, usually dismissed because popular desktop address book applications apparently do not handle AGENT. It sounds reasonable that multiple entities for a business would be agents. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
On 27 Jun 2007, at 23:09, Thom Shannon wrote: I know this topic comes up a lot and we'd all like to see Microformats change the lives of millions of ordinary internet users, that's why we're all here! My friend just asked me an interesting question, is Microformats the right name for it? Sorry, but this discussion seems absurd to me. Microformats is a good name for developers. It encompasses a large range of different, mostly discrete and often unrelated data formats. It has nothing at all to do with user-facing exposure of that data. No-one is ever (read: should ever) create a web browser with a ‘Get Microformats’ button other than as a developer testing tool. But the idea that we need some other name with ‘Super’, ‘Hyper’ and ‘Smart’ in the name is verging on the hilarious. Here's what should happen: Developers will use a microformat in their page to describe reviews, addresses or calendar appointments. User agents will then expose them as… reviews, addresses and calendar appointments. I cannot for the life of me see why we are trying to abstract useful functionality at a user-end with a nonsensical name like ‘Smart Data’ when ‘Address’, ‘Event’ and ‘Location’ have served the English language very well so far. Finally, an all-encompassing term for all microformats going to be useless to end users. Apart from the aforementioned abstraction of what the data really is and really should be used for, microformats are so varied that a generic term will be meaningless. XOXO and Geo? Branding them ‘Hyper Smart Data Enabled’ isn't going to help an end user any more than ‘microformat’. Exposing functionality where useful is. And that functionality doesn't need a µf.org endorsed name; the functionality should be named as appropriate, not the data format. To draw a parallel: We do not ‘consume HTML documents’, we ‘read web pages’. Consumers of microformats will not ‘consume Smart Data’ they will ‘add contacts to their address books’, ‘print address labels’, ‘find other employees of this organisation’ and ‘show a map of this location’. I would strongly discourage any implementer from trying to dress up simple functionality with a catch-all term. It will be utterly confusing users with yet another hunk of IT jargon. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Date of Death in hCard
On 27 Jun 2007, at 20:33, Andy Mabbett wrote: There having been no comments, much less objections, I intend to proceed with this, using died as the property name, in five days from the time of posting. I have no objections to this. It's a useful extension to hCard as a ‘profile’ format; which it is very much being used for on the web. I would be prepared to have ‘hCard profile extensions’ separated from hCard, though. There's value in the hCard spec being 1:1 with vcard, especially with regards compatibility with desktop tools. Although this particular extension wouldn't have a major impact on that use, if we're to open the can of adding new fields, I'd like it considered that we clearly separate it, perhaps into a separate specification, citing hCard as the base and then fully specifying additional fields. That way it remains valid to implement hCard for the purposes of just representing vCard on the web, and more suitable implementations could embrace these extensions as well. Does anyone agree? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Generating valid unique IDs for hAtom
On 22 Jun 2007, at 07:07, Toby A Inkster wrote: What's wrong with using Permalinks as an id? If you need to make several entries onto the hAtom feed referencing the same URL, then you can just add #ref-20070722, #ref-20070723 and so on to the end of the URL to make it unique. The best starting point about identifiers for Atom was written by Mark Pilgrim: • http://diveintomark.org/archives/2004/05/28/howto-atom-id It includes instructions on generating Tag URIs and also explains why permalinks are sub-optimal as IDs. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
On 28 Jun 2007, at 14:40, Thom Shannon wrote: I get your point, but as Alex pointed out people are interested in this microformats thing but dont want to call it that, journos are refusing to talk about it because the term 'microformats' would only appeal to developers, and not the average reader But it is impossible to have a meaningful or descriptive name that catches all microformats, let alone to an ‘average reader’. I'm also not sure which subset of journalists wish to write articles about the data formats themselves, but whose audience would balk at a reference to microformats.org. Anyone writing for the average user would surely be writing in the context of browser functionality (as and when it ships: namely Firefox 3). And when referencing the functionality of those features, it makes most sense to use the terms ‘address’, ‘location’, ‘map’, ‘event’, ‘appointment’, ‘contact’ or ‘business card’ and other such words. That's all microformats are to end users. We provide a standardised, digital form of those physical-world concepts. A journalist could write ‘Firefox 3 allows you to interact with business cards and events in web pages like never before, bridging the gap between the pages you read and other applications’. That is surely a gazillion times better than trying to encourage ‘Firefox 3 ships with support for Hyper Data, which allows web pages to…’. Such a generic and meaningless term not only adds nothing, but distracts from the real benefits of Microformat deployment (by which I mean all the name suggestions in this thread, not just my facetious overuse of the word ‘hyper’). We need a way to get across to people that content can be lifted out of pages and used in useful ways, when those pages support it. And people need to call it something. Maybe it should just be Reusable Information. For the people who will be putting the data in the pages — developers — we have names. Yes, microformats and h* is all very techie, but that's perfectly acceptable for developers. End-users don't need to know anything at all about _how_ or _why_ their new browser functionality works, only that it's an awesome new feature that's going to improve their life. Who is the group in the middle that this wooly new terminology is going to serve? I don't see it. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
On 28 Jun 2007, at 15:59, Thom Shannon wrote: yes, it's a thing, it's different. FF3 can't just add any address you see to your address book, its a specific kind of address that just looks the same, and you need a browser or plugin or something that understands that specific thing So whats the thing called, micro-what? or Resuable Data (with the MF icon!) I'm still not sure there's anything there that can't be served with the term ‘rich web page’ or ‘semantic web page’ — two terms already in use. What is the semantic way to mark up a business card? hCard. If some reference to the page specifics is required in documentation somehow, does ‘microformatted content’ or ‘microformatted web page’ not suffice? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF Tools for Internet Explorer?
On 9 May 2007, at 00:22, Charles Iliya Krempeaux wrote: The rumor is that IE8 will have native support for Microformats. Please correct me if I'm wrong, but I'm not sure those rumours have ever been supported by anything out of Microsoft. There's a lot of circumstantial reasoning (Microsoft's efforts with Live Clipboard, Vista shipping with an iCalendar based calendar application and updated Contacts app), but I don't know that any IE developer has substantiated the link even slightly. In fact, last I recall reading for IE.next on the IE blog was a focus on JavaScript and DOM scripting enhancements. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
