Marcels Fazit:

Neben dem Chaos, das das Einbinden offener Standards, oder Möchte-gern-Standards für Entwickler unattraktiv macht, gibt es noch ein weiteres Problem, dem sich das Open Web, das dezentrale Web, gegenüber sieht: Die Protagonisten, also die Fürsprecher und die, welche die Grundlagen entwerfen und weiter entwickeln, haben es bis dato versäumt, einen effektiven Hebel zu erschaffen, um Anreize für alle Seiten zu generieren, die dann zu den virtuosen selbstverstärkenden Effekten führen.

Die im Gespräch angemerkte Kurzlebigkeit der Standards ist das Gegenteil eines effektiven Hebels: Sie treibt die notwendige Entwicklerseite frustriert weg.

Ich bin im übrigen mittlerweile fast der Meinung, dass jede signifikante Weiterentwicklung von Webstandards von Unternehmen wie Google und Facebook kommen wird und muss. Denn in deren Produkten steckt der Hebel schon drin. Das bringt uns allerdings wieder zurück zu den Argumenten von Bradbury zur Abhängigkeit bei Web-APIs.

Obwohl ich das immer noch nicht so richtig wahr haben will hat Marcel mit seiner Aussage wohl den Nagel auf den Kopf getroffen. Ein aktuelles Beispiel: Schema.org! Ich beschäftige mich seit mehr als 5 Jahren mit Microformats und RDFa… für mich ist Schema.org einfach nur ignorant!
Für die meisten Webentwickler ist Schema.org aber der erste Berührungspunkt mit Websemantiken, wieso sich also weiter mit Altlasten herumplagen. Google, Microsoft und Yahoo! einigen sich auf Schema.org… ein simples Format und ein valider Usecase. Damit wird Schema.org zum neuen defacto Standard ohne je den Anspruch darauf erhoben zu haben:

schema.org is not a formal standards body. schema.org is simply a site where we document the schemas that three major search engines will support.

Der Punkt ist: Was bringens uns “Standards” von W3C und IETF wenn sie niemand unterstützt. Wir brauchen Formate die ein Bedürfnis decken und von der breiten Masse akzeptiert werden… ob man sie jetzt “Standard” nennt oder nicht!

(Um dieses Thema geht es übrigens auch in meiner Kolumne im nächsten Webstandards Magazin.)

Knapp zwei Jahre nach dem ersten Teil, komme ich endlich mal zu Nummer 2 Nach den ganzen Diskussionen um schema.org und Microformats V2 ist es mal wieder an der Zeit, am Image von Microdata zu arbeiten.

Namenskollisionen und Namespaces

class-Attribute werden in erster Linie zum Gestalten (CSS) und für JS benutzt! Laut “The State of Web Development 2010” setzen nur knapp 35% aller Befragten Microformats ein, das heißt mehr als 65% haben keine Ahnung von Mikroformaten oder setzten sie nicht ein. Das kann zu zwei Problemen führen:

1. Microformats werden oft durch Re-Designs zerstört. Facebook ist wohl das prominenteste Beispiel, nach einem Re-Design verschwanden alle Microformats von den Profilseiten.
2. Es werden fälschlicherweise class-Attribute interpretiert die gar nichts mit Microformats zu tun haben nur zufällig den passenden Namen tragen. Anfällige Klassen sind z.B. url (hCard), photo (hCard), summary (hReview), description (hReview) oder author (hAtom).

Um diesem Problem Herr zu werden denkt die Community Tantek Çelik über eine Art Namespace-Erweiterung nach.

Microformats

So könnten Microformtas demnächst folgendermaßen aussehen:

<div class="h-card">
 <span class="p-fn">Max Mustermann</span>
</div>

Dabei steht:

• “h-*” für die root-names, z.B. “h-card”, “h-event”, “h-entry”
• und “p-*” für “simple” (Text) Properties, z.B. “p-fn”, “p-summary”

…und es gibt noch eine reihe weiterer Prefixes. Das ist zwar schön und gut und verhindert sicherlich einen Großteil der Namenskollisionen und man kann seinen Entwicklern sicherlich auch eintrichtern, alle x- Klassen in ruhe zu lassen… aber man mach damit jegliche Semantik kaputt. Nix mehr mit Plain Old Semantic HTML (POSH):

POSH encapsulates the best practices of using semantic HTML to author web pages. Semantic HTML is the subset of HTML 4.01 (or XHTML 1.0) elements and attributes that are semantic rather than presentational. The best way to learn and understand POSH is to do it.

…und semantic class names:

Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Außerdem verkompliziert man das, jetzt noch so einfach zu nutzende, Format unnötig. Wann ist etwas eine id (i-*) oder eine Nummer (n-*) und was ist mit Attributen, die sowohl aus auch sein können?

Microdata

Der Microdata Teil ist relativ schnell abgehandelt… Durch die Trennung von Semantik und Design kommt es bei Mircodata per se zu keinen Kollisionen:

<div itemtype="http://microformats.org/profile/hcard" itemscope>
 <span itemprop="fn">Max Mustermann</span>
</div>

Informationen Referenzieren

Informationen stehen auf Webseiten nicht immer so nahe beieinander, so dass es oftmals schwer ist, alle Daten mit einem HTML Attribut zu umschließen.

Microformats

Je komplizierter das Format oder der Anwendungsfall, desto mehr stößt man mit Microformats an die grenzen des machbaren. HTML 4 bietet keinerlei Mechanismen, den oben angesprochenen Problem zu lösen, deshalb greift die Microformtas-Community zu einer recht Kreativen Lösung: dem include-pattern.

<div class="vcard">
 <a class="include" href="#author-name"></a>
</div>

<span class="fn n" id="author-name">Max Mustermann</span>

oder:

<div class="vcard">
 <object class="include" data="#author-name"></object>
</div>

<span class="fn n" id="author-name">Max Mustermann</span>

Nette Idee mit etlichen Unschönheiten:

• Leere HTML-Elemente
• Zweckentfremdung von Object- bzw. Link-Element
• Die Nutzung von <object /> führt zu einigen Problem bei einigen Versionen von Internet Explorer, Safari und Firefox

Microdata

Microdata löst das Problem mit dem itemref-Attribut:

<div itemscope
     itemtype="http://microformats.org/profile/hcard"
     itemref="author-name">
 ...
</div>

<span itemprop="fn n" id="author-name">Max Mustermann</span>

Viel mehr gibt es dazu eigentlich nicht zu sagen

Fazit

Als Fazit, passt hier sehr gut ein Satz den ich auch als Fazit im aktuellen Webstandards-Magazin verwende:

Microformats sind und bleiben Plain Old Semantic HTML und man sollte auch in Zukunft keinesfalls darauf verzichten sie einzusetzen, selbst mit dem Risiko einer fehlerhaften Implementierungen oder Namenskollisionen, „erzieht“ die Nutzung von Microformats einen jeden Webentwickler dazu „schönen“ und „sprechenden“ HTML-Code zu schreiben.

…um HTML-Code aber wirklich maschinenlesbar zu machen, wird es Zeit auf Microdata und RDFa zu setzen. Microformats haben den Weg für bessere und native Lösungen geebnet und haben weiterhin ihre Daseinsberechtigung aber man sollte nicht mehr als dem Format machen, als es leisten kann.

Seit Freitag gibt es wieder eine neue Ausgabe des Webstandard-Magazins, mit dem Fokus auf Communities.

…als hätte ich es gerochen, passt das Thema meiner Kolumne recht gut zu den aktuellen Diskussionen um Microformats, Microdata, RDFa und schema.org. Noch genauer: Es geht um die Zukunft der Microformtats.

Dieses Jahr feierten die Microformats ihren 8. Geburtstag. In diesen 8 Jahren haben sich mehr als zwei Milliarden hCards im Yahoo! Index angesammelt und die Mikroformate dominieren mit 94% Googles rich snippets (im Verhältnis zu RDFa und Microdata). Trotz allem sind Microformats eine Übergangslösung und es wird Zeit für einen richtigen Standard!

Wie sieht die Zukunft der Microformats aus, was ist ist geplant, machen Microformats neben Microdata und RDFa überhaupt noch Sinn usw.

Also los… kaufen! Zack, zack!

Auf schema.org findet man eine Übersicht alle Schemas die die Suchgiganten in Zukunft unterstützen werden:

This site provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results, making it easier for people to find the right web pages.

Was mich besonders freut: Die Schemas basieren alle auf Microdata und wer meinen Blog regelmäßig verfolgt wird wissen, dass ich das Format sehr schätze! Hier ein Beispiel wie eine Person mit dem neuen Schema aussieht:

<div itemscope itemtype="http://schema.org/Person">
  <span itemprop="name">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="image" />
</div>

Soweit so gut, aber… es werden WIEDER einmal weder bestehende Microformats, noch RDFa Schemas auf Microdata portiert, was dazu führt dass mir spontan 5 unterschiedliche Formate einfallen um Personen zu beschreiben: hCard (Microformats), Data-Vocabulary (RDFa- und Microdata-Beschreibung genutzt von den rich-snippets), FoaF (RDFa), vCard (RDFa), schema.org (Microdata).

Die Microformats-Community hat von Anfang an eines richtig gemacht: Es gibt nur eine Stelle an der Microformats definiert werden und man muss einen relativ langwierigen Prozess befolgen um ein neues Format zu definieren. Das führt zwar dazu dass es bisher nur eine handvoll Schemas veröffentlicht wurden, diese aber wohl definiert sind und in der Regel auf bisherigen Formaten aufbauen. Die hCard ist beispielsweise ein 1:1 Abbild der vCard.

Schema.org ist zwar eine ganz nette Idee aber man hat leider versäumt sich mit der Microformats-, RDFa-, RDF- Community zusammenzusetzen und einen gemeinsamen Konsens zu finden!

Wäre folgendes Beispiel so viel komplizierter?

<div itemscope itemtype="http://microformats.org/profile/hcard">
  <span itemprop="fn">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="photo" />
</div>

…oder das?

<div itemscope itemtype="http://www.w3.org/2006/vcard/ns">
  <span itemprop="fn">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="photo" />
</div>

Das Format ist letztendlich Geschmackssache… der eine mag lieber die einfachen Microformats, der andere steht mehr auf RDFa und ich bevorzuge Microdata, man sollte sich aber endlich auf ein einheitliches Schema einigen!

Yahoo! zählt knapp zwei Milliarden hCards in ihrem Index und trotzdem diktiert man Webseitenbetreibern etwas komplett anderes auf…

Also hier ein paar echt großartige Microformats-News… Zusammengefasst!

Microformats Shiv

Glenn Jones, der hier schon wegen etlicher Dinge, Scripte, Addons, usw. erwähnt wurde, bastelt an einem “[...] light weight cross brower JavaScript Microformats parser“. Der Parser basiert auf der Microformats API von Mozilla und funktioniert in allen gängigen Browsern. Unterstützte Formate: hCard, hCalendar, hResume, hReview, hAtom, XFN, adr, geo, tag.

Draggables

Und schon wieder Glenn Jones, diesmal mit einem Microformats/HTML5/JavaScript/Drag&Drop – Dingens. Mit dem Script ist es möglich, Microformats zwischen unterschiedlichen Seiten per drag&drop auszutauschen:

Having observed users connect to sites using OAuth without really understanding what exchange of data has taken place, I decided to investigate other metaphors/conventions that might be more transparent. Draggables is a series of demos that explore the use of drag and drop to directly exchange data between web sites.

Das ist nicht ganz neu, aber gar keine schlechte Idee… ein Profil mit der Maus auf das Adressbuch zu ziehen ist sicherlich verständlicher als die ganze OAuth oder OpenID Hin-und-Her-Leiterei… zumindest für Web-Neulinge!

hForms

…und nochmal Glenn Jones. Zu guter Letzt treibt er noch das hcard-input-brainstorming voran um auch Profil- oder Event-Eingaben zu standardisieren… hForms oder Microforms so zu sagen

Use hCard properties as class names on form elements inside a container (such as a containing <fieldset> or the containing <form>) to indicate that those form elements accept values with the semantics of the respective hCard properties.

So, genug für heute! Demnächst gibt’s dann auch noch ein bisschen mehr zu OStatus for WordPress… natürlich ausführlich und nicht zusammengefasst

Schlaft schön!

user A takes a photo of B from their phone and posts it, B gets notified that they are in a photo, C who follows A gets the photo and leaves a comment, A and B get notified of the comment, where users are on at least 2 (ideally 3) different services each of which is built with a different code base.

» Social Web Acid Test (SWAT) v0 draft
» SWAT0 – FederatedSocialWeb

Papal ID == OpenID + Payment?
Diese Grafik hab ich in einer Präsentation zu “The OpenID Foundation is looking for input from online retailers” gefunden.

…klingt spannend!

» Quelle: The OpenID Foundation is looking for input from online retailers

Open Mail Format
Eine Anleitung wie man Microformats in HTML – E-Mails versteckt.

The Open Mail Format allows notifications to be tagged so that automated agents (electronic mail services) can provide users with custom information based on the content of the email.

OMF is based on the idea of microformats (http://microformats.org), which allow both humans and software to interpret the information encoded in the email. [...]

» What is Open Mail Format
» Microformats

Meine Favoriten sind:

Microformats

select * from microformats where
url='http://wait-till-i.com'

…findet diverse Microformats. » Direct Link

Mehr dazu hier: SELECT * FROM microformats

OpenID

select * from openid.discover where
normalizedId="http://www.yahoo.com/"

…klassische OpenID-Discovery. » Direct Link

select * from openid.yadis where
uri="http://www.yahoo.com/"

…YADIS-Discovery. » Direct Link

…und es gibt noch ‘ne Reihe anderer OpenID Queries… es sollte sogar möglich sein einen kompletten OpenID-Client mit YQL zu bauen.

OAuth

select * from oauth where uri='http://example.com'
and consumerKey='asd123' and consumerSecret='zxc456'
and callbackUri='http://example.com';

…sendet einen OAuth-Request. » Direct Link

pubsubhubbub

insert into pubsubhubbub.publisher
(hub_url, topic_url) values
('http://pubsubhubbub.appspot.com/publish',
'http://developer.yahoo.com')

…sendet ein Update an das angegebene Hub. » Direct Link

Webfinger

select * from webfinger where
account='pfefferle@gmail.com'

…Webfinger-Discovery. » Direct Link

OpenSocial

select * from opensocial.people

…sendet eine OpenSocial People-Anfrage. » Direct Link

Social Graph API

select * from socialgraph.lookup where
q = "notizblog.org" AND edo = "1"

…ermöglicht Zugriff auf Googles Social Graph API. » Direct Link

Atom

select * from atom where
url='http://notizblog.org/feed/atom'

…interpretiert Atom-Feeds mit allen möglichen Erweiterungen, beispielsweise der ActivityStreams-Extension. » Direct Link

Vielleicht bekomm’ ich die Tage ja auch mal eine Query zusammen

» PseudoID: Enhancing Privacy for Federated Login

Contacts API Draft
Das W3C arbeitet gerade an einem “unified address book” welches alle Adressbücher eines Users vereint und dieses über eine API auch wieder für dritte zugänglich macht.

Every operating system and a large number of web-based service providers have different ways of representing address book information. [...] This specification defines the concept of a user’s unified address book – where address book data may be sourced from a plurality of sources – both online and locally. This specification then defines the interfaces on which 3rd party applications can access a user’s unified address book; with explicit user permission and filtering.

Hört sich ein wenig nach Synaptic bzw. Fedarated bzw. Distributed bzw. Decentralized Web an…

» Contacts API

CORS, Scraping, and Microformats
Michaels Mahemoff beschreibt wie man mit Hilfe von Cross-Origin Resource Sharing und Microformats das Web zu einer einzigen API machen könnte.

Cross-Origin Resource Sharing makes it possible to do arbitrary calls from a web page to any server, if the server consents. It’s a typical HTML5 play: We could do similar things before, but they were with hacks like JSONP. Cross-Origin Resource Sharing lets us can achieve more and do it cleanly.

Nicht ganz unbedenklich… aber definitiv ein interessanter Gedankengang!

via snirgel

» CORS, Scraping, and Microformats
» Cross-Origin Resource Sharing

» Making W3C the Place for New Web Standards
» Wiki-Seite

UfXtract jetzt Open Source
Glenn Jones hat den Quellcode seines Microformats-Parsers UfXtract veröffentlicht.

UfXtract is a fast and easy to use .Net microformats parser. With a few lines of code you can load and parse microformats from Urls or HTML strings. You can then extract the data directly in .Net or convert it into JSON, JSON-P or XML.

» GitHub Repository
» ufXtract Webservice

Aus foaf+ssl wird WebID
Die OpenID Community hat ja bereits erkannt dass der Otto-Normal-User einige Probleme mit URLs als Identifier hat. Das scheint das W3C aber nicht weiter zu stören.

A Web ID is an “Identifier” (an “HTTP URI” in fact), for Entity “You” [...] It looks like a URL and feels like a URL, but isn’t solely a URL, due to the inherent Identity/Access duality of HTTP scheme URIs.

Hört sich simpel an

» A Web ID
» OpenWeb-Podcast: Episode 25 – FoaF+SSL

AddThis baut ausschließlich auf OExchange
AddThis integriert in Zukunft nur noch Dienste die das OExchange-Protokoll unterstützen. Mal schau’n wie konsequent sie sind

Today, we’ve released a new workflow for submitting new services (i.e. social networks, online communities, etc) to the AddThis Service Directory that requires all new services support the sharing protocol OExchange.

» OExchange Support Now Required for New Service Submission
» OExchange Submission Flow