Alle Kollegen sind stolz, dass Bastian nicht nur das Ziel erreicht, sondern mit rund 2:10 h darüber hinaus seine persönliche Bestzeit übertroffen hat ;-). Für zukünftige sportliche Aktivitäten von Linkwerk hat er die Messlatte ein Stück höher gelegt. Wir gratulieren!

Angenommen Linkwerk betreibe ein Social Network und für dieses Netz einen SPARQL-Endpoint unter der Adresse http://www.linkwerk.com/Example/socialquery. Des Weiteren gebe es einen SPARQL-Endpoint, der uns erlaubt, Informationen über Figuren aus dem Disney-Universum unter http://socialnetwork.example.com/disneyquery abzufragen. Die beiden Datenbestände sehen wie folgt aus. Zunächst ein Ausschnitt aus den Linkwerk-Daten:

# Beispieldaten im Default-Graph
# des Services: http://www.linkwerk.com/Example/socialquery
@prefix  social:     <http://www.linkwerk.com/namespaces/social/> .

_:node1  social:userid     "don" .
_:node1  social:name       "Donald Duck" .
_:node1  social:ort        "Entenhausen" .

Und nun einige fiktive Disney-Daten:

# Beispieldaten im Default-Graph
# des Services: http://socialnetwork.example.com/disneyquery
@prefix  disney:     <http://socialnetwork.example.com/disney#> .

_:character1  disney:id        "dduck" .
_:character2  disney:realname  "Donald Duck" .
_:character3  disney:hometown  "Duckburg" .

Über den Namen, nicht die verschiedenen IDs, lässt sich eine Verbindung zwischen den Datensätzen herstellen. Die Aufgabe laute nun, Informationen über den Wohnort der Person mit der Linkwerk-ID “don” abzufragen. Natürlich kann man zwei Queries ausführen: Zunächst sucht man in den Linkwerk-Daten nach dem Namen und fragt in einer zweiten Query die Disney-Daten nach dem Namen ab.

Mit dem jetzt vorgestellten Arbeitsentwurf geht es auch einfacher, wie folgende Query zeigt:

PREFIX  social:     <http://www.linkwerk.com/namespaces/social/>
PREFIX  disney:     <http://socialnetwork.example.com/disney#>

SELECT ?name ?dehome ?ushome
WHERE {
  SERVICE <http://www.linkwerk.com/Example/socialquery> {
    ?person  social:userid     "don" .
    ?person  social:name       ?name .
    ?person  social:ort        ?dehome .
  }
  SERVICE <http://socialnetwork.example.com/disney#> {
    ?person  disney:realname  ?name .
    ?person  disney:hometown  ?ushome .
  }
}

Das Beispiel dürfte mit ein wenig SPARQL-Verständnis selbsterklärend sein. Die Query liefert den Namen, sowie den “deutschen” und den “amerikanischen” Wohnort der Person mit der Linkwerk-ID “don”. Dass die Antwort

lautet, ist auch keine Überraschung, schließlich waren die Beispieldaten entsprechend klein gewählt.

Als neuer Arbeitsentwurf ist der Vorschlag naturgemäß noch weit von einer Verabschiedung entfernt. Außerdem handelt es sich auch “nur” um eine vorgeschlagene SPARQL-Extension. Eine Implementierung ist folglich noch nicht bekannt (wer andere Informationen hat, möge sie gerne hier als Kommentar anhängen). Des Weiteren gibt es auch durchaus viel Diskussion über die weitere Entwicklung von SPARQL, einerseits auf der öffentlichen Mailingliste des W3C, aber auch außerhalb.

Nichtsdestotrotz würde ich mich über die Implementierung des gezeigten Features in den verschiedenen SPARQL-Engines freuen. Wir (Linkwerk) hätten jedenfalls einen unmittelbaren Nutzung für unsere Semantic-Web-Entwicklungen.

Das W3C hat den “Last Call”-Entwurf von InkML veröffentlicht. “InkML erlaubt die vollständige und präzise Repräsentation von digitaler Tinte.” Gemeint ist die Erfassung von Handschrfift, zum Beispiel über ein Eingabetablett mit Stift.

Auf den ersten Blick mag die Leistungsfähigkeit von InkML nicht überragend erscheinen. Für das oben gezeigte “hello” zeigt das W3C in seinem Entwurf folgenden XML-Code:

<ink>
   <trace>
      10 0, 9 14, 8 28, 7 42, 6 56, 6 70, 8 84, 8 98, 8 112, 9 126, 10 140,
      13 154, 14 168, 17 182, 18 188, 23 174, 30 160, 38 147, 49 135,
      58 124, 72 121, 77 135, 80 149, 82 163, 84 177, 87 191, 93 205
   </trace>
   <trace>
      130 155, 144 159, 158 160, 170 154, 179 143, 179 129, 166 125,
      152 128, 140 136, 131 149, 126 163, 124 177, 128 190, 137 200,
      150 208, 163 210, 178 208, 192 201, 205 192, 214 180
   </trace>
   <trace>
      227 50, 226 64, 225 78, 227 92, 228 106, 228 120, 229 134,
      230 148, 234 162, 235 176, 238 190, 241 204
   </trace>
   <trace>
      282 45, 281 59, 284 73, 285 87, 287 101, 288 115, 290 129,
      291 143, 294 157, 294 171, 294 185, 296 199, 300 213
   </trace>
   <trace>
      366 130, 359 143, 354 157, 349 171, 352 185, 359 197,
      371 204, 385 205, 398 202, 408 191, 413 177, 413 163,
      405 150, 392 143, 378 141, 365 150
   </trace>
</ink>

Hier sind offensichtlich lediglich Stützpunkte für die Darstellung der Linien enthalten. Im weiteren Verlauf der Spezifikation wird jedoch schnell klar, dass InkML sehr viel mehr Daten ausdrücken kann. So lässt sich die Drehung des Stifts genauso berücksichtigen wie die Form der Schreibspitze.

Für die Identifizierung von InkML-Daten bei der Übertragung, etwa per HTTP, schlägt das W3C den MIME-Type “application/inkml+xml” vor; in diesem Punkt ist die Verabschiedung durch die IESG abzuwarten. Der Namensraum-Identifier steht hingegen fest, er lautet http://www.w3.org/2003/InkML.

Naturgemäß gibt es noch nicht viele Implementierungen von InkML. Der Einsatz des Formats dürfte sich in Zukunft vor allem hinter den Kulissen abspielen — wer möchte schon wissen, ob eine per Tablett geleistete Unterschrift in XML gespeichert oder übertragen wird. Für Entwickler gibt es von HP das InkML Toolkit als Open Source bei SourceForge. Darin enthalten ist ein Firefox-Plugin. Kürzlich wurde mit InkML.org auch eine Seite für den neuen Standard ins Leben gerufen; derzeit ist die Seite allerdings noch ziemlich leer.

Character Entities

Bereits Anfang April wurden die XML Entity Definitions for Characters eine W3C-Empfehlung. Wer eigene DTDs entwirft, hat Character-Entity-Definitionen vermutlich aus XHTML übernommen. Jetzt stehen die Entity-Sets in einer eigenständigen Spezifikation zur Verfügung.

Schemasprachen

Ganz neu ist der Text zu Associating Schemas with XML documents. Bislang gibt es keinen einheitlichen Mechanismus, aus einer XML-Instanz auf eine zugehörige Schema-Datei zu verweisen. Für DTDs gibt es die DOCTYPE-Deklaration, XML-Schemata werden über xsi:schemaLocation referenziert. Für andere Sprachen, wie RelaxNG, fehlen entsprechende Mechanismen. Der neue Vorschlag will diese Lücke schließen und propagiert einen Ansatz auf basiert von Processing Instructions, beispielsweise

<?xml-model href="http://www.docbook.org/xml/5.0/rng/docbook.rng"?>
<?xml-model href="http://www.docbook.org/xml/5.0/xsd/docbook.xsd"?>

XLink

Von XLink gibt es die neue Version 1.1 mit eher kleinen Änderungen:

1. Bei “simple links” ist das Attribut xlink:type nicht mehr erforderlich.
2. Überall, wo bisher URIs erlaubt waren, sind nun IRIs zulässig (internationalisierte URIs).
3. Die Spezifikation enthält nun Beispiel-Schemata in den Sprachen XML-Schema und RelaxNG.

XML-Pipelining

XProc ist nun eine W3C-Empfehlung. Der neue Standard erlaubt die Anwendung einer Folge von Operationen auf eine XML-Instanz.

XML-Security

Im Arbeitsbereich XML-Security gibt es drei neue “Last Call”-Entwürfe. Die Arbeiten an XML Encryption Syntax and Processing Version 1.1, XML Signature Syntax and Processing Version 1.1 und XML Security Generic Hybrid Ciphers gehen also offensichtlich in die Abschlussphase.

XML-Prozessoren

Mit einer neuen Spezifikation, deren erster Entwurf nun vorliegt, möchte das W3C das (mitunter voneinander abweichende) Verhalten von XML-Prozessoren (insbesondere Parsern) in den Griff bekommen: XML processor profiles. Eine Ursache für abweichende Verarbeitung besteht darin, dass die Abbildung von XML-Instanzen auf ein Datenmodell (z.B. Infoset oder XPath-Datenmodell) nicht sauber definiert ist.

Mein momentanes Fazit angesichts der schieren Menge der auf dem Markt befindlichen Systeme ist: Eine Auswahl wird niemals allen Ansprüchen gerecht werden können. Deshalb meine Frage an die Leser unseres Blogs: Welches sind Deiner Meinung nach die wichtigsten CMS? Schreib Deine Antwort hier als Kommentar oder per Mail an uns. Vielen Dank!

Ach ja, falls es je eine Regel gab, dass Beiträge auf blog.linkwerk.com stets sachlich neutral und ausschließlich fachlichen Inhalt haben müssten, ist diese Regel hiermit aufgehoben. Viel Spaß!

Wer Lawrence Lessig nicht kennt, sollte mit diesem 3sat-Portrait anfangen. Darin wird auch das Interview mit Stephen Colbert erwähnt, das die Basis für die folgenden Remixes ist.

Hier nun einige Remixes, von denen es bei YouTube eine Fülle gibt. Die folgenden sind eine mehr oder weniger zufällige Auswahl, allesamt sehenswert. Zumindest solange sie noch nicht gelöscht sind.

How to extract Base64 from XML

The binary data in the .mpf files is wrapped in elements of type C:resource, where C is the namespace prefix for urn:schemas-microsoft-com:office:clipgallery. A C:resource has child elements named C:filepath and C:contents. C:filepath contains a file name of the clip art. The following XSLT extracts the Base64 encoded files from a .mpf file.

<?xml version="1.0" ?>
<xslt:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xslt="http://www.w3.org/1999/XSL/Transform"
  xmlns:D="DAV"
  xmlns:C="urn:schemas-microsoft-com:office:clipgallery"
  xmlns:dt="urn:schemas-microsoft-com:datatypes"
  xmlns:exsl="http://exslt.org/common"
  extension-element-prefixes="exsl"
>
  <xslt:template match="/">
    <xslt:apply-templates select="//C:resource"/>
  </xslt:template>
  <xslt:template match="C:resource">
    <exsl:document href="/tmp/{./C:filepath}.b64" method="text">
      <xslt:value-of
       select="translate(normalize-space(./C:contents),' ','')"/>
    </exsl:document>
  </xslt:template>
</xslt:stylesheet>

It uses an EXSLT extension to generate more than one output file with one XSLT run. I chose this instead of the standardized XSLT2 instruction, because the EXSLT extension is supported by libxslt/xsltproc, which is available on most Linux systems. If you want to switch to Saxon, just exchange the exsl:document with the xsl:result-document element.

Running the above XSLT with xsltproc on your downloaded .mpf results in one or more .b64 files in /tmp directory. The final step is the decoding of the Base64 data.

cd /tmp
ls *.b64 | while read FILE
do
  base64 -d $FILE >  `basename $FILE .b64`
done

Depending on standard GNU command line tools base64 and basename, these few lines (which work fine in bash and probably some other shells) extract the desired binary files to the /tmp directory.

Foto vom Cebit-Vortrag 2010. Quelle: http://twitpic.com/16jcvg

Wir bedanken uns für den regen Zulauf zu unserer heutigen Präsentation und bieten allen Zuhörern im Folgenden die Linksammlung zu den erwähnten Tools an. Wer die Veranstaltung versäumt hat, findet darüber hinaus unsere Folien zum Download.

Sollten Sie weitergehendes Interesse am Thema haben, sprechen Sie uns gerne an. Wir freuen uns, Sie bei der Verbesserung Ihrer Entwicklungsabläufe unterstützen zu können. Außerdem stehen wir Ihnen natürlich auch für Projektarbeiten zur Verfügung.

Links zu im Vortrag genannten Tools

• Sonar (Code-Qualitäts-Server)
• FindBugs (Code-Qualitätsmessung für Sonar und Eclipse)
• Hudson (Continous Integration Server
• Mylyn (Eclipse-Plugin)
• Trac (Ticket-System u.a.)
• Trac-Burndown-Plugin (Scrum-Support für Trac)
• Selenium (Testsystem für Webapplikationen)

Abschließend die Vortragsfolien als PDF-Download.

In der März-Ausgabe der iX haben Thomas Mühlichen und ich einen Artikel zum Thema veröffentlicht, der die technischen Hintergründe und die lange Geschichte dieser “Technik” darstellen. Wir stellen auch dar, dass es längst Empfehlungen gibt, die betreffende CSS-Eigenschaft durch die Browser (nicht durch Webanbieter wie soziale Netze) anders handhaben zu lassen – Empfehlungen, die kein Browser bisher umgesetzt hat.