XML-Ecke

Struktur in den Content!

Von der Website zur Web App

Web App im Firefox OS Simulator

Web App im Firefox OS Simulator

Mozilla hat ein Mantra: Wer eine Website gestalten kann, ist auch ein App-Entwickler. Das Open-Source-Projekt will so auch das mobile Web wieder offen machen, es aus den “walled gardens” der Android- und iOS-Welten herausführen. Dieser Blog Post will Anspruch und Wirklichkeit miteinander vergleichen.

Für Apps mit hohen Anforderungen an die Prozessorleistung sind die nativen Apps für ein bestimmtes mobiles Betriebssystem zurzeit noch deutlich leistungsfähiger. Viele Apps aber bereiten lediglich Informationen für die Nutzung auf mobilen Geräten auf – Informationen, wie sie von Websites bislang meist für die Verwendung im Browser und auf Desktop-Geräten bereitgestellt werden. Solche Angebote lassen sich sinnvoll auch als Web-App bereitstellen. Der Vorteil gegenüber der Darstellung im mobilen Browser: Die App kann direkt auf Smartphone-Funktionen wie Kamera oder Geolokalisierung zugreifen und für die Anwendung nutzbar machen.

Das Mozilla-Projekt hat einen relativ einfachen Workflow für die Entwicklung von Web Apps eingerichtet. Eine zentrale Rolle spielt dabei eine einfache JSON-Datei – das Datenaustauschformat der JavaScript Object Notation stellt ähnlich wie XML strukturierte Daten für die Nutzung von Webanwendungen bereit. Bei einer Web-App heißt das App Manifest. Diese JSON-Datei wird mit der Endung .webapp abgespeichert und enthält einige zentrale Daten der App:

{
  "name": "meine App",
  "description": "bei meiner App geht es um das hier...",
  "launch_path": "/index.html",
  "icons": {
    "60": "/images/icon-60.png",
    "64": "/images/icon-64.png",
    "128": "/images/icon-128.png"
  },
  "developer": {
    "name": "mein name",
    "url": "http://meine_website.de"
  },
  "default_locale": "de"
}

Wichtig ist der vollständige Pfad zur Datei mit dem Einstieg zu den Inhalten der Web-Anwendung – es genügt nicht, hier nur das Root-Verzeichnis anzugeben, wie es im Mozilla-Dokument zum Web Manifest angegeben ist.

Das App Manifest von Mozilla ähnelt dem Manifest der Google Extensions, das ebenfalls elementare Daten einer Webanwendung im JSON-Format festhält. Wünschenswert wäre da eine baldige Standardisierung.

Das App Manifest wird auf den Server hochgeladen, ins gleiche Verzeichnis, in dem auch die Daten der Website liegen. Da das App Manifest im Root-Verzeichnis der Website liegt, kann angenommen werden, dass beide vom gleichen Web-Entwickler stammen, was die Sicherheit erhöhen soll. Die App will mit einem Icon auf dem Smartphone-Desktop gestartet werden – mit Blick auf unterschiedliche Systeme kann man hier png-Bildchen in verschiedenen Auflösungen gestalten und im Web Manifest angeben. Eine Anleitung dazu gibt es auch von Mozilla.

Schließlich muss auf dem Server noch eine .htaccess-Datei erstellt oder ergänzt werden, damit der Browser weiß, was er mit dieser merkwürdigen Datei mit der Endung webapp anfangen soll:

AddType application/x-web-app-manifest+json .webapp

Nun kann das App Manifest in einem Validator überprüft werden. Wenn bei dieser Prüfung keine Fehler beanstandet werden, ist die Entwicklung der Web App theoretisch schon abgeschlossen:

Der Firefox OS Validator testet das Web Manifest

Der Firefox OS Validator testet das Web Manifest

Die Web-App soll ähnlich wie eine native App bedient werden, also auf dem mobilen Gerät nicht im Browser-Fenster erscheinen, sondern als eigenständige Anwendung. Dafür sorgt die Web Runtime von Mozilla. Die Funktionen dieser API können entweder in den HTML-Code der beim Start aufgerufenen Webseite eingefügt werden – oder der Web-Designer überlässt das einer Plattform wie Github oder dem Firefox Marketplace. Die Web Runtime installiert das Icon auf den Desktop des Betriebssystems, startet von dort aus die App in einem rahmenlosen Fenster und sorgt dafür, dass Hardware-Funktionen wie die Kamera von der App adressiert werden können. Die Web Runtime ist Bestandteil der Browser-Rendering-Technik Gecko und soll in einer künftigen Version des Firefox-Browsers mit integriert werden.

Damit die App auf Funktionen des Smartphones zugreifen kann, hat Mozilla eine WebAPI bereitgestellt: Dazu gehören eine Vielzahl von JavaScript-Funktionen wie der Zugriff auf Uhrzeit, Geolokalisierung oder Kontakte. Für die volle Einbindung der App ins Smartphone gibt es außerdem die WebActivities – hier fordert die App vom Anwender eine Entscheidung zur ergänzenden Nutzung einer anderen App. Zum Beispiel will die WebActivity “pick” ein Foto haben – der Anwender kann nun entscheiden, ob er ein Foto aus der Sammlung gespeicherter Bilder nimmt oder mit der Kamera ein neues Foto aufnimmt. Um etwa die Geodaten vom Smartphone auszulesen, ruft eine JavaScript-Anweisung die Methode getCurrentPosition() auf, was nur wenige Codezeilen erfordert:

?View Code JAVASCRIPT
var geolocation = document.querySelector("#geolocation"),
            geolocationDisplay = document.querySelector("#geolocation-display");
        if (geolocation && geolocationDisplay) {
            geolocation.onclick = function () {
                navigator.geolocation.getCurrentPosition(function (position) {
                    geolocationDisplay.innerHTML = "<strong>Latitude:</strong> " + position.coords.latitude + ", <strong>Longitude:</strong> " + position.coords.longitude;
                    geolocationDisplay.style.display = "block";
                },
                function (position) {
                    geolocationDisplay.innerHTML = "Failed to get your current location";
                    geolocationDisplay.style.display = "block";
                });
            };
        }

Für die Offline-Nutzung einer Web App kann ein AppCache in die index.html eingebunden werden. Ein Cache Manifest listet die URLs der Dateien auf, die offline bereitgestellt werden sollen. Diese Technik nutzt die Fähigkeiten von HTML5 für das Application Caching.

Das Verhalten der App im Firefox OS von Mozilla kann man im Firefox-Browser mit Hilfe eines Simulators testen. Dieses virtuelle Firefox-Smartphone muss zunächst mit der Maus “entriegelt” werden: Dazu schiebt man den Pfeil nach oben und klickt dann rechts auf das Schloss-Symbol. Mit gedrückter Maustaste kann man nun zwischen den verschiedenen Desktops hin und her blättern und einige der installierten Apps starten. Wenn man dem Simulator die URL der Datei mit dem Web Manifest mitgeteilt hat, wird auch diese App installiert und kann nun in ihrem Verhalten getestet werden.

Dabei zeigt sich, dass der Weg von der Website zur Web App in der Praxis doch etwas länger ist als zunächst gedacht. Beim Versuch, meine mit Joomla 2.5 gestaltete Website www.miramis.de zur App zu machen, zeigt sich, dass sich diese nicht automatisch an das mobile Display anpasst – obwohl ich dafür ein responsives Template nutze. Auf einem iPhone oder einem Android-Smartphone wird so dafür gesorgt, dass die Darstellung der Joomla-Website optimal an das mobile Display angepasst wird. Dieselbe Website in Verbindung mit einem Web Manifest wird im Firefox OS Simulator aber in der großen Desktop-Auflösung dargestellt. Hier ist also die Nutzung eines mobilen Frameworks wie JQuery mobile der sinnvollere Weg – wie das dann im Firefox OS Simulator aussieht, zeigt der Screenshot ganz oben.

Mit JQuery mobile entwickelte Web-Anwendungen unterstützen denn auch die ganze Vielfalt von mobilen Plattformen – von Android über iOS bis Blackberry 10 und Windows Phone. Eine Web App für Firefox OS aber kann das Versprechen einer plattformübergreifenden Nutzung bislang noch nicht einlösen: Sie kann zurzeit nur mit Firefox OS, mit dem Firefox-Browser für Android und mit Firefox-Testversionen Nightly und Aurora gestartet werden. Der Ansatz von Mozilla ist interessant und zukunftsfähig. So hoffe ich, dass er in diesem Jahr zügig weiterentwickelt wird – in Richtung Standardisierung beim Web Manifest und in Richtung einer breiten Plattformunterstützung im Sinne eines rundum offenen Webs.

Posted in Im Lauf der Zeit | Tagged , , , , | Leave a comment

IPTC treibt Entwicklung von rNews voran

Mit dem neuen Projekt schema.org kommt langsam Bewegung ins semantische Web. Da passt es, dass auch der International Press Telecommunications Council (IPTC) die Entwicklung seines neuen Standards rNews vorantreibt. Auf einem Arbeitstreffen in Berlin billigte die Organisation die Version 0.5 des Standards, der erst im April  vorgestellt wurde. Die “draft version” berücksichtigt die Erfahrungen aus den ersten Tests zur Umsetzung von rNews.

Das Markup von rNews, so erklärte Stuart Myles während der Beratungen in Berlin, bemühe sich um einen ausgewogenen Kompromiss zwischen einer möglichst einfachen Anwendung ohne tiefgreifende Änderungen an bestehenden HTML-Dokumenten und einer einfachen Nutzung ohne komplizierte Software-Werkzeuge zum Parsen, also zur Syntaxanalyse von rNews. Die Änderungen machen das Modell eingängiger und einfacher. So wird nun nicht mehr von “Tags”, sondern von “Concepts” gesprochen – als Basisklasse für Angaben zum Inhalt von Nachrichten . Die zunächst als eigene Klasse festgelegten Angaben zur Überschrift mit der Bezeichnung “Hed” wurden unter den Eigenschaften der Klasse NewsItem subsumiert. Und die bisherige Klasse TickerSymbol wurde nun zu den Eigenschaften von Organization gestellt.

Der IPTC will auch Möglichkeiten für das Mapping, für die Transformation von rNews in andere Formate anbieten, darunter HTML5-Mikrodaten und JSON. Für Verleger soll es damit so einfach wie möglich gemacht werden, rNews in bestehende Workflows einzubinden. “rNews erschließt den Wert der Veröffentlichung von Metadaten bei Online-News, indem es dafür einen einfach zu verwenden Standard bereitstellt, der ausschließlich Web-Technologien verwendet”, erklärte Myles, der die Arbeitsgruppe Semantisches Web beim IPTC leitet und sich bei Associated Press um Nachrichtenformate kümmert. Bis zum nächsten IPTC-Treffen im Oktober soll rNews die Entwurfsphase hinter sich lassen und in der Version 1.0 vorgelegt werden.

Die vom IPTC gepflegten XML-Formate NewsML oder NITF sind vor allem dazu gedacht, Nachrichten-Feeds in die Content-Management-Systeme der Medienunternehmen zu bringen. Diese können den aktuellen Content dann als HTML-Dokumente mit semantischen Metadaten in ihre Web-Angebote bringen. Ob dabei rNews, das schlichtere Mikroformat hNews oder eine künftige Lösung im Rahmen des Suchmaschinen-Projekts schema.org zum bestimmenden Standard werden wird, entscheiden vermutlich nicht zuletzt auch wirtschaftliche Interessen im Spannungsfeld zwischen Medienunternehmen und Suchmaschinen-Betreibern.

Posted in Im Lauf der Zeit | Tagged , , , | Leave a comment

Google vereinfacht Geocoding-Service

Rund zehn Monate nach der Einführung von Version 3 (V3) der Google Maps API hat Google auch seinen Geocoding-Service vereinfacht, der Postadressen oder Ortsangaben in Geodaten umwandelt. Auch hier ist jetzt kein besonderer Key für die Nutzung des Dienstes mehr erforderlich. Es genügt die Anforderung beim Webservice nach dem Schema:

http://maps.google.com/maps/api/geocode/output?parameters

Der Platzhalter “output” wird ersetzt durch Angaben zum gewünschten Ausgabeformat, wobei XML oder das schlanke JSON zur Verfügung stehen. Statt “parameters” wird die gewünschte Adresse angegeben, also zum Beispiel:

http://maps.google.com/maps/api/geocode/xml?address=Weifert-Janz-Straße+1+Mainz&sensor=false

Der erforderliche Parameter “sensor” gibt an, ob die Anfrage von einem Gerät mit der Erfassung von Geodaten kommt oder nicht. Optional kann mit dem Parameter “region” die geografische Region eingegrenzt werden, was etwa bei Orten sinnvoll ist, die es in mehreren Ländern gibt. Ohne diese Differenzierung zeigt der Geocoder zum Beispiel bei der Abfrage von Toledo den im US-Staat Ohio gelegenen Ort an. Erst die Präzisierung mit “region=es” sucht nach der spanischen Stadt. Für die Bezeichnung der Region werden die Länder-Codes der Top-Level-Domains (ccTLD) verwendet, also etwa “de” für Deutschland. Das Ergebnis der Abfrage im JSON-Format führt alle bekannten Informationen auf, darunter auch die Geodaten der geografischen Länge und Breite:

{
  "status": "OK",
  "results": [ {
    "types": [ "street_address" ],
    "formatted_address": "Weifert-Janz-Straße 1, 55122 Mainz, Deutschland",
    "address_components": [ {
      "long_name": "1",
      "short_name": "1",
      "types": [ "street_number" ]
    }, {
      "long_name": "Weifert-Janz-Straße",
      "short_name": "Weifert-Janz-Straße",
      "types": [ "route" ]
    }, {
      "long_name": "Mainz",
      "short_name": "Mainz",
      "types": [ "locality", "political" ]
    }, {
      "long_name": "Mainz",
      "short_name": "MZ",
      "types": [ "administrative_area_level_2", "political" ]
    }, {
      "long_name": "Rheinland-Pfalz",
      "short_name": "RP",
      "types": [ "administrative_area_level_1", "political" ]
    }, {
      "long_name": "Deutschland",
      "short_name": "DE",
      "types": [ "country", "political" ]
    }, {
      "long_name": "55122",
      "short_name": "55122",
      "types": [ "postal_code" ]
    } ],
    "geometry": {
      "location": {
        "lat": 50.0042904,
        "lng": 8.2410587
      },
      "location_type": "RANGE_INTERPOLATED",
      "viewport": {
        "southwest": {
          "lat": 50.0011490,
          "lng": 8.2379114
        },
        "northeast": {
          "lat": 50.0074443,
          "lng": 8.2442067
        }
      },
      "bounds": {
        "southwest": {
          "lat": 50.0042904,
          "lng": 8.2410587
        },
        "northeast": {
          "lat": 50.0043029,
          "lng": 8.2410594
        }
      }
    }
  } ]
}

Die JSON-Elemente lassen sich nun mit wenigen Codezeilen als Javascript-Variablen definieren und für Kartendarstellungen verwenden – zum Beispiel:

?View Code JAVASCRIPT
var latitude = myJSONResult.results.location.lat;
var longitude = myJSONResults.location.lng;

Dabei verlangt Google in seinen Nutzungsbestimmungen, dass nur Karten auf der Grundlage seiner eigenen APIs für Google Maps oder Google Earth verwendet werden dürfen. Neben der Auflösung von Adressen wird auch das Reverse Geocoding unterstützt, also die Umwandlung von Geodaten mit den Angaben der geografischen Breiten- und Längengrade in Adressen. Für das oben gezeigte Beispiel funktioniert dies etwa auf diese Weise:

http://maps.google.com/maps/api/geocode/json?latlng=50.0042904,8.2410587&sensor=false
Posted in Im Lauf der Zeit | Tagged , , | Leave a comment

XMLSpy von Altova spricht auch JSON

Screenshot XMLSpy 2010Mit jeder Version lernt das Altova-Paket für die XML-Plattform neu hinzu. Nachdem vor einem Jahr die Unterstützung für die Business Reporting Language (XBRL) im Zentrum stand, spricht der XMLSpy 2010 jetzt auch JSON, das Datenformat JavaScript Object Notation.

“Es gibt zahllose Anwendungen, bei denen XML sinnvoller ist, und es gibt zahllose andere Anwendungen, bei denen JSON Vorteile hat”, erklärt Altova-Vorstandschef Alexander Falk auf Fragen von xml-ecke.de. “XML hat die bessere Infrastruktur von ergänzenden Standards (wie XML Schema, XSLT, XPath, etc.). Das macht XML zu einer viel reichhaltigeren Plattform und bietet mehr Flexibilität. Aber man muss auch die Eleganz, Effizienz und Einfachheit von JSON anerkennen.” Anstatt beide als konkurrierende Technologien zu betrachten, unterstütze die Version 2010 von Altova MissionKit XML ebenso wie JSON und lasse den Anwendern die freie Wahl.

Bereits die Standard-Edition von XMLSpy 2010 ermöglicht so die Erstellung von JSON-Dateien (siehe oben) – ebenso wie die von zahlreichen anderen Formaten wie CML (Chemical Markup Language), die Multimedia-Sprache SMIL, XHTML oder DOCX (OpenXML) – allerdings fehlt weiterhin das Open Document Format (ODF). Die Professional und die Enterprise Edition der Software bieten darüber hinaus weiter gehende Funktionen wie Eingabehilfen oder die Umwandlung von JSON in XML und umgekehrt.

Falk wandte sich dagegen, XML und JSON gegeneinander auszuspielen. Wenn man einigen Bloggern und Entwicklern zuhöre, wirke die Debatte manchmal wie ein “Religionskonflikt”. Beide Techniken seien geeignet, um strukturierte wie unstrukturierte Daten zu erfassen. “JSON konzentriert sich vor allem darauf, diese Daten wirksam, das heißt mit sehr wenig Overhead zu speichern und zu übertragen, während sich XML auf eine reichhaltige Umgebung konzentriert, die Entitäten sowie einen Mechanismus einschließt, der Metadaten und Erweiterbarkeit unterstützt.” Tatsächlich mache die Erweiterbarkeit den Hauptunterschied aus, erklärte der Altova-Vorstandschef. Daneben biete JSON auch nicht derart weitreichende Möglichkeiten für die Verarbeitung von XML-Dokumenten (mit XSLT), die Abfrage (mit XQuery) oder die gezielte Auswahl von Elementen (mit XPath). Wenn es aber um die Erfassung von einfachen Daten gehe und um ihre Übertragung zwischen Client und Server, “glänzt JSON mit seiner Einfachheit und – wie manche sagen – mit seiner besseren Lesbarkeit”.

Der XMLSpy ist Bestandteil der umfassenden XML-Suite Altova MissionKit 2010. Neben der Unterstützung für JSON enthalten die verschiedenen Anwendungen des Pakets nach Angaben des Herstellers die 70 “most wanted” Features. Unter anderem wurde die XBRL-Unterstützung weiter ausgebaut. Für Web-Services können die erforderlichen WSDL-Dateien nun nach dem neuen Standard WSDL 2.0 erstellt werden. Und in StyleVision, dem Programm zur Erstellung von XSLT-Formatvorlagen für die grafische Gestaltung von Dokumenten auf der Basis von XML-Daten, gibt es eine neue Möglichkeit, um Layout-Container zu platzieren.

Wie sieht Alexander Falk die Zukunft von XML? “Die Leute reden immer weniger über XML, weil es so allgegenwärtig geworden ist, dass es einfach für selbstverständlich gehalten wird.” Schließlich sei auch niemand mehr aufgeregt, wenn es um die Datenübertragung im Netz mit dem TCP/IP-Protokoll gehe oder um die Möglichkeit, die vielfältigsten Zeichensätze mit Unicode zu erfassen. “Sobald sich diese Standards fest etablieren, sind sie nicht mehr ‘aufregend’. Aber man braucht immer noch die Werkzeuge, um damit zu arbeiten.” Das solide XML-Fundament biete die Grundlage für die Erweiterung von Dokumentenformaten, die zuverlässige Wiederverwendbarkeit sowie die Verarbeitung von Daten, erklärte Falk. “Aus meiner Sicht sieht die Zukunft von XML sehr hell aus.”

Posted in Im Lauf der Zeit | Tagged , , | Leave a comment