notizBlog » JSON

oAlternative

Matthias Pfefferle — Tue, 15 Nov 2011 01:07:50 +0000

Was das OpenWeb so kompliziert macht ist das Wörtchen “alternativ“!

OpenID Discovery basiert auf Meta-Tags, alternativ funktioniert aber auch XRDS(-Simple)/Yadis oder Webfinger.
OpenID stellt über SREG Profilinformationen bereit, alternativ aber auch über Attribute Exchange.
RDFa 1.1 ist folgendermaßen aufgebaut:
```
  ...
  John Doe
  ...
```
alternativ aber auch:
```
  John Doe
```
…oder:
```
  John Doe
```
OpenSocial, oEmbed, ActivityStrea.ms und host-meta benutzen JSON, alternativ aber auch XML
OAuth verschlüsselt mit HMAC-SHA1, alternativ aber auch mit RSA-SHA1 oder PLAINTEXT

To be continued…

Wie viel Komplexität man sich sparen könnte wenn man sich auf eine Variante beschränken würde.

OpenID ABC

Matthias Pfefferle — Sat, 30 Apr 2011 12:50:33 +0000

OpenID.net hat einen kleinen Ausblick auf die nächste OpenID Version veröffentlicht… Eine Mischung aus OpenID Connect, OAuth 2 und einer Menge JSON-APIs. Schade dass Webfinger scheinbar nicht berücksichtigt wurde und statt dessen die Simple Web Discovery zum Zuge kommt.

OpenWeb-Notizen: OStatus, Facebook, pubsubhubbub

Matthias Pfefferle — Wed, 06 Oct 2010 22:25:50 +0000

How to implement OStatus?
Evan Prodromou (der Gründer von StatusNet) hat eine Schritt-für-Schritt-Anleitung veröffentlicht, wie man die eigene Seite verOStatust!

Making your application a full-fledged participant in the federated social web is not easy, but gradual and incremental improvements can make your users’ activities visible to others.

» How to OStatus-enable Your Application

Is your Site OStatus-Ready?
…und jede neue Implementierung will auch überprüft werden!

» Are you ready for Ostatus .. or not ?

pubsubhubbub + json
Facebooks Real-time-API ist eine Art Mischung aus pubsubhubbub+json+OAuth2.

» pubsubhubbub
» Real-time Updates

hCardMapper für WordPress

Matthias Pfefferle — Wed, 02 Apr 2008 19:21:51 +0000

Wie in meinem letzten Post über den hCardMapper beschrieben, war es in der Tat nicht möglich den Microformats-Parser/Proxy ohne weitere Probleme auszutauschen. Die generierten JSON Formate der einzelnen Parser (ufXtract, hKit, mofo) unterscheiden sich an einigen Stellen zu sehr um sie alle gleich behandeln zu können. Soweit zur schlechten Nachricht…

Die gute Nachricht ist, dass sich Gordon Oheim (der Macher des hCardMappers) nochmal alle JSON Formate vorgenommen und eine neue Version gebastelt hat:

v0.94 – Added better support for JSON returned by Optimus, ufXtract and hKit.

Der Mapper sollte also mit mofo, Optimus, ufXtract and hKit problemlos funktionieren.

Die nächste tolle Nachricht ist, dass Gordon auch auf einen kleinen Änderungswunsch von mir sofort eingegangen ist, so dass wir euch jetzt eine hCardMapper Edition von dem WordPress hCard-Commenting Plugin anbieten können .

Download: ~~hCardMapper for WordPress v0.1~~ hCardMapper bei WordPress.org

Wenn ihr immer die aktuelle Version haben wollt, hier ist der Link zum SVN.

Ich hab das Plugin auch mal auf notizBlog aktiviert und würde mich über euer Feedback freuen. Macht es Sinn über das Admin-Menü zwischen beiden Versionen (hCard-Commenting und hCardMapper-Commenting) zu wechseln?

Ein dickes Danke nochmal an Gordon für seine tolle und schnelle Arbeit… tolles Script.

hCard Mapper

Matthias Pfefferle — Fri, 28 Mar 2008 08:41:36 +0000

…oder How to use hCards to fill in forms.

hCardMapper ist eine JavaScript-Klasse (basierend auf Prototype) um Kontakt- oder Profil-Formulare mit Hilfe einer hCard automatisch zu füllen, ähnlich wie bei bragster.com oder getsatisfaction.com.

Das schöne an hCardMapper ist seine flexible Struktur. Die JavaScript Klasse ist so aufgebaut, dass sie eigentlich Microformats-Parser unabhängig funktionieren sollte, da sie die Daten über einen “Proxy” abfrägt. Die einzige Vorgabe ist, dass dieser Proxy eine JSON formatierte hCard (jCard) zurückgibt. Das Problematische an dieser Variante ist, dass jeder Parser unterschiedliche Ergebnisse liefert… ich werde es heute abend mal mit dem hKit-Parser testen.

Ein weiter Vorteil ist die Formular-Unabhängige Programmierung die es ermöglicht, das Script auch problemlos auf vorhandene Formulare anzuwenden. Über mappnings werden die hCard-Attribute den entsprechenden Formular-Felder zugeordnet.

Event.observe(window, 'load', function() {
  hcr = new com.omniacomputing.HCardMapper({
    register: true,
    proxy: '/hcardmapper/hcard?uri=',
    insertBelowEl: 'hcr-hook',
    mappings: {
      given_name: 'first',
      family_name: 'last',
      tel: {tel: 'phone', work: 'phone', cell:'phone'},
      email: 'email',
      org: {org: 'company', organization_name: 'company'},
      url: 'website',
      street_address: 'street',
      postal_code: 'zip',
      locality: 'town'
    }
  })
});

Quelle: http://lib.omnia-computing.de/hcardmapper

Tolle Idee, mal schau’n wie gut das Script mit den (oben schon erwähnten) unterschiedlichen Verarbeitungsweisen der Parser umgeht…

Microformats und JSON

Matthias Pfefferle — Sun, 30 Dec 2007 22:58:32 +0000

Ich bin vor einiger Zeit schon auf das microJSON Projekt gestoßen und fand die Idee, ein einheitliches JSON Format für alle Microformats zu erstellen, prinzipiell nicht schlecht, deshalb habe ich auch versucht microJSON für mein hCard-Commenting Script einzusetzen.

Bei genauerem Betrachten gibt es bei der jCard aber zwei unschöne Eigenschaften:

Das n Attribut wird in JSON als name dargestellt.
Das fn Attribut wird gat nicht abgebildet.

Da ich, um den Username in den WordPress Kommentaren darzustellen, auf fn angewiesen bin, habe ich mir verschiedene andere “hCard to JSON” Services angeschaut.

Test-hCard: http://pfefferle.org/static/microformats/hcard-test.html

Überblick der einzelnen JSON Objekte

Optimus:

{
  from: "http://pfefferle.org/static/microformats/hcard-test.html",
  title: "hCard Test",
  hcard: {
    "adr": {
      "street-address": "Street",
      "region": "State",
      "locality": "City",
      "postal-code": "12345",
      "country-name": "Country"
    },
    "email": {
      href: "mailto:mail@examle.org",
      value: "mail@examle.org"
    },
    "fn": "Mustermann Max",
    "org": "Organisation",
    "tel": "111-222-333",
    url: [
      "http://example.org",
      "http://pfefferle.org/static/microformats/aim:goim?screenname=aim",
      "http://pfefferle.org/static/microformats/ymsgr:sendIM?yim"
    ]
  }
}

ufXtract:

// ufXtract
{
  "vcard": [{
    "fn": "Mustermann Max",
    "n": {
      "given-name": ["Mustermann" ],
      "family-name": ["Max" ]
    },
    "adr": [{
      "street-address": ["Street" ],
      "locality": "City",
      "region": "State",
      "postal-code": "12345",
      "country-name": "Country"
    }],
    "org": {
      "organization-name": "Organisation"
    },
    "email": ["mail@examle.org" ],
    "tel": ["111-222-333" ],
    "url": [
      "http:\/\/example.org\/",
      "aim:goim?screenname=aim",
      "ymsgr:sendIM?yim"
    ]
  }]
}

hKit Service (hKit + JSON)

json[{
  "fn":"Mustermann Max",
  "adr":{
    "street-address":"Street",
    "postal-code":"12345",
    "country-name":"Country",
    "region":"State",
    "locality":"City"
  },
  "email":"mail@examle.org",
  "org":"Organisation",
  "tel":"111-222-333",
  "url":[
    "http:\/\/example.org",
    "http:\/\/pfefferle.org\/static\/microformats\/aim:goim?screenname=aim",
    "http:\/\/pfefferle.org\/static\/microformats\/ymsgr:sendIM?yim"
  ],
  "n":{
    "given-name":"Mustermann",
    "family-name":"Max"
  }
}]

microJSON (jCard)

{
"vcard":{
  "name":{
    "given":"Mustermann",
    "family":"Max"
  },
  "org":"Company",
  "email":"mail@examle.org",
  "address":{
    "street-address":"Street",
    "postal-code":"12345",
    "country-name":"Country",
    "region":"State",
    "locality":"City"
  },
  "tel":"111-222-333",
  "aim":"aim",
  "yim":"yim",
  "url":"http:\/\/example.org"
}

Leider unterscheidet sich jedes dieser JSON Formate (wenn auch teilweise nur gering) vom anderen, was ja prinzipiell kein wirklich großes Problem ist. Zum Problem wird es erst dann, wenn man einen dieser Dienste durch einen anderen ersetzt, da ein solcher Vorgang immer mit Änderungen am Quellcode verbunden ist.

Es ist im SOA Ansatz zwar nicht definiert, dass die Services ähnlich wie bei der Multi-Tier-Architektur austauschbar sein sollten, es würde jedoch eine Menge an Arbeit erspahren.

Microformats sind wohl definierte offene Standards, wieso nicht auch die Austauschformate wohl definieren?

Weiterführende Links:

Optimus, der Microformats Transformer

Matthias Pfefferle — Wed, 19 Sep 2007 15:39:26 +0000

Optimus ist ein Script zum Umwandeln von nahezu allen Microformats in JSON oder XML. Es wäre ganz schick den JSON output an die microJSON Formate anzupassen oder umgekehrt, um eine standardisierte Verarbeitung zu ermöglichen.

microJSON – Microformats in JSON

Matthias Pfefferle — Sun, 16 Sep 2007 10:08:10 +0000

microJSON ist ein Projekt von Jon Sykes und Jim Barraud. Es geht darum, Microformats in Form der JSON Schreibweise darzustellen. Die Idee von JSON ist, einen einfachen Datenaustausch von Objekten oder auch anderen Datenstrukturen wie z.B. Arrays zwischen Client Systemen (z.B. dem WebBrowser) und Server Systemen zu realisieren. Der Vorteil von JSON ist, dass sie kaum Overhead produziert und in JavaScript über die eval() Funktion wieder ganz einfach in ein Objekt gewandelt werden kann.

Beipiel einer hCard:


  
    given

    middle
    family
  
  org

  email
  
    street

    city,state/province,postal
    country

  
  phone
  AIM

  YIM

Die gleiche hCard als jCard:

{
"vcard":{
  "name":{
    "given":"John",
    "additional":"Paul",
    "family":"Smith"

  },
  "org":"Company Corp",
  "email":"john@companycorp.com",
  "address":{
    "street":"50 Main Street",
    "locality":"Cityville",
    "region":"Stateshire",
    "postalCode":"1234abc",
    "country":"Someplace"

  },
  "tel":"111-222-333",
  "aim":"johnsmith",
  "yim":"smithjohn"
}

Neben den Abbildungen der Microformats hCard (jCard) und hCalendar (jCalendar) sind auch die Format jAtom, jResume, jReview, jAtom und jResume geplant. Weitere abbildung gibt es für normale Formulare (jForm), sowie auch für RSS Feeds (jRSS).

MicroJSON sind meiner Meinung nach eine sehr gute Idee, wenn man Bedenkt dass viele gute Microformats Parser, wie z.B. der vom Firefox Addon Operator verwendete ufParser, auf JavaScript basiert.