Dies ist ein »Abfallstück« aus meiner Ausrüstungsplanung das ich nicht mehr brauche und das deshalb in meinen Blog kommt. Habe mich mal dafür interessiert, einen Linux-basierten PDA anzuschaffen und dazu einige Recherchen angestellt .. praktische Erfahrung mit den vorgeschlagenen Geräten habe ich aber keine. Hier das Ergebnis meiner Recherchen, die besten Empfehlungen zuerst:

  • Sharp Zaurus SL-C3200. Siehe http://www.mobiletechreview.com/Sharp-Zaurus-C3200.htm. Das neueste Modell der Linux-basierten Sharp SL-C Serie. In Europa wohl nur erhältlich über dynamism.com, ein Anbieter der neueste japanische Geräte auf den europäischen Markt bringt. Das Gerät sollte mit einer Solid State Disk, Compact Flash Karten für WLAN und Bluetooth und 2 weiteren Akkus (zum Glück nicht fest verbaut) aufgerüstet werden.
  • Nokia N800. Siehe http://www.dynamism.com/n800/main.shtml. Linux-basiert; bietet ein GPS-Modul, verwendbar mit Google Maps. Gegenüber dem erfahrungsgemäß zu langsamen Nokia N770 vorzuziehen.
  • Motorola Linux Smartphone. Siehe http://www.golem.de/0507/39220.html.
  • Compaq iPaq. Ein Linux-basierter PDA.
  • Apple iPhone. Siehe http://de.wikipedia.org/wiki/IPhone. Basiert auf Mac OS X und damit auf BSD-Unix. Besonders interessant beim iPhone ist das Multitouch-Touchpad mit dem man alle Anwendungen nur mit den Fingern bedienen kann.

Für weitere Informationen vergleiche den Linux PDA Guide.

To convert a bulk of blog posts I created in the past years to the format of Deepest Sender I wrote a small Python script that converts all events from an iCalendar (.ics) file to XML files for Deepest Sender. By the way, this is my first real-world Python script and I am astonished as to the ease, clarity and brevity of Python. Note that you need to save the script posted here with UTF-8 encoding; line mangling is just a visibility / screen width and template problem, just copy and paste the source into a text editor and you’ll be fine! Have fun!

#! /usr/bin/env python
# -*- coding: utf_8 -*-
#
# converts an iCal file with blog entries (as appointments) to Deepest Sender XML
#
# Arguments (in order):
# file the iCal file to convert
# output directory directory where the output files for Deepest Sender go into, one per blog post
#
# The appointments in the iCal input file are converted one by one to blog post XML files as understood by the XUL dektop blogging
# plugin “Deepest Sender” (http://deepestsender.mozdev.org). An inferior alternative to this script’s approach is to convert a HTML
# table as produced by korganizer’s HTML table export format for appointments.
#
# iCal file prerequisites:
# all VEVENT components have the SUMMARY property (else output file name lacks a title)
# no two VEVENTS on one day have the same SUMMARY property (else output files are overwritten)
#
# Deepest sender file structure (note that it is UTF-8 encoded):
# <?xml version=”1.0″ encoding=”utf-8″?>
# <entry>
# <subject><![CDATA[blog entry title]]></subject>
# <event><![CDATA[blog entry content with HTML markup]]></event>
# </entry>
#
# TODO: the filename must only contain a date, not a time, even if the DTSTART property contains one
# TODO: write the values of the DTSTART, CREATED and LAST-MODIFIED properties into the blog post text (via component.decoded())

import sys # argv, …
from xml.dom.minidom import parse, parseString
from codecs import open # overwrite internal open() to enable UTF-8 file access
from icalendar import Calendar, Event
# get it from http://pypi.python.org/pypi/icalendar/1.2 ; if you don’t want to clutter your distro by installing it system-wide,
# copy the directory iCalendar-1.2/src/icalendar/ to the script’s directory

def filenamestr(thestring):
thestring = thestring.replace(‘ ‘,‘_’)
thestring = thestring.replace(u‘»’,)
thestring = thestring.replace(u‘«’,)
thestring = thestring.replace(‘/’,‘bzw.’) # slash in a filename is really bad …
while thestring[-1:] is ‘.’: # remove trailing dots as a dot and filename extension will be appended
thestring = thestring[:-1]
return thestring

calfilename = sys.argv[1]
cal = Calendar.from_string(open(calfilename,‘rb’).read())
outputdir = sys.argv[2]
while outputdir[-1:] is ‘/’: # remove trailing slash if present
outputdir = outputdir[:-1]

entrycount = 0;
for event in cal.walk(‘VEVENT’):
# decompose blog entry; event.decoded() is Unicode already
date = event.decoded(‘DTSTART’)
title = event.decoded(‘SUMMARY’)
content = event.decoded(‘DESCRIPTION’,)
content = content.replace(‘n’,‘<br />’) # the simplest means to convert text to HTML, just as Deepest Sender does when
# writing in WYSIWYG mode; we eliminate n here as blogger.com would create additional <br /> from this

print ‘[processing:’, date, title, ‘]’
# print event.property_items() # debug utility

# calculate output file’s name
filename = str(date) + ‘.PRIVATE.’ + filenamestr(title) + ‘.xml’

# write blog entry to its output file
dsfile = open(outputdir + ‘/’ + filename, ‘w’, ‘utf_8’) # will only accept Unicode strings!
dsfile.write(
u‘<?xml version=”1.0″ encoding=”utf-8″?>n’ +
u‘<entry>n’ +
u‘ <subject><![CDATA[‘ + title + u‘]]></subject>n’ +
u‘ <event><![CDATA[‘ + content + u‘<br /><br />Datum: ‘ + str(date) + u‘]]></event>n’ +
u‘</entry>n’
)
dsfile.close()
entrycount += 1

print ‘———-nconversion successful (‘ + str(entrycount) + ‘ entries processed)’

Bisher verwendet wurde das Journal von korganizer zum Speichern aller Blog-Einträge. Dieses ist jedoch sehr unausgereift:

  • man führe Korrekturen und Erstellung am besten direkt in blogger.com durch und sichere den Artikel dann durch Kopieren des HTML-Quelltextes in einen (neuen oder ersetzten) Journal-Eintrag in korganizer; denn den HTML-Quelltext von in HTML geschriebenen korganizer Journal-Einträgen kann man nur über den Quelltext der iCal-Datei erreichen und auch dann ist Nachbearbeitung notwendig (Suchen und Ersetzen: »;« durch »;«, »”« durch »”«, »,« durch »,«, »n« durch »«). Außerdem erzeugt das Journal beim Editieren zusätzliche Tags und Formatierungen (z.B. »<p>«, und insbesondere auch Zeilenumbrüche nach jeder Zeile) die in Blog-Posts auf blogger.com stören, und es werden Tags entfernt (z.B. »<h2>«) die in Blog-Posts enthalten sein sollen.
  • Achtung: korganizer speichert die Journal-Artikel nicht direkt nachdem man sie eingegeben hat; von außen ausgelöst werden kann das Speichern nur durch Beenden von kontact (Beenden der korganizer-Erinnerungsfunktion ist unnötig).

In Anbetracht dieser Unausgereiftheit und weil eine Integration mit kontact ohnehin nicht gegeben ist sollte besser ein echtes Offline-Blogging-Programm mit Schnittstelle zu blogger.com und sauberem HTML-Quelltext und HTML-WYSIWYG-Editor eingesetzt werden. So etwas kann es geben über die Blogger API (http://code.google.com/apis/blogger/overview.html). Ebenfalls möglich ist es so z.B. die Blog-Posts bei Bedarf auf einer eigenen Homepage zu veröffentlichen, oder den Ort zu wechseln wo die Blogs gehostet werden (weg von blogger.com zu WordPress auf der eigenen Homepage zum Beispiel).

Programme dazu:

  • Firefox mit Deepest Sender 0.8.0 (https://addons.mozilla.org/firefox/1811/); bisher die einzige Anwendung die die jetzt aktuelle GData API von blogger.com unterstützt; sieht nach der einzig zu empfehlenden Alternative aus, u.a. da sie als einzige einen WYSIWYG-Editor besitzt.
  • der Browser Flock wie dokumentiert in http://blog.yoda.ch/?p=1016 ; evtl. auch zu empfehlen
  • blogtk; zu Starten als BloGTK; man muss außerdem die Pakete python-gtkhtml2 und gtkhtml3.14 installieren, diese sind aufgrund eines Bugs leider nicht in den Paket-Abhängigkeiten aufgeführt; leider hat das Programm keine ausreichende Unterstützung für die API von blogger.com und wird seit 2005 nicht mehr weiterentwickelt
  • drivel; in den Ubuntu-Quellen enthalten aber geringer Funktionsumfang, dafür aber Unterstützung für Atom / Blogger 2.0; leider verwendet blogger.com jedoch wieder eine neue Schnittstelle, die GData API (siehe http://code.google.com/apis/gdata/blogger.html ).
  • gnome-blog; für die Gnome-Taskbar
  • kicker-blogger; für die KDE-Taskbar
  • blognix (http://blognix.sourceforge.net); veraltet und nicht weiterentwickelt
  • MozBlog (http://mozblog.mozdev.org/); seit 2004 nicht weiterentwickelt
  • Liste weiterer Applikationen: http://help.blogger.com/bin/answer.py?answer=42347 ; keine weiteren für Linux relevanten Applikationen

Eine alternative (evtl. bessere) technische Möglichkeit ist eventuell: Publishing über SFTP, wie bei blogger.com möglich (http://www.blogger.com/adv-create-blog.g). Das heißt die Blog-Artikel (manuell oder sonstwie erstellt) lädt man auf einen eigenen Server hoch und gibt dessen (S)FTP-Zugangsdaten bei blogger.com an. So kann sowohl eine (wahrscheinlich schon existierende) Joomla-Komponent als auch blogger.com dieselben Daten verwenden. Damit umgeht man auch alle Probleme mit eventuell verbotenen Zugriffsarten auf blogger.com Blogs.

Beim Posten trat folgender Fehler auf: »Error sending post: [Line 2, Column 255, element published] Invalid date/time format: ‘2007-07-23T19:51Z&+39;.«. Auf http://community.livejournal.com/deepestsender/129187.html wird dieser Fehler ausgiebig dokumentiert aber keine Lösung angeboten. Offizieller Bugreport: https://www.mozdev.org/bugs/show_bug.cgi?id=17037 .

Wenn man in den Einstellungen auf blogger.com das Datums-Header-Format auf »Jul 23, 2007« (der erste Eintrag) und das Format des Zeitstempels auf »10:15 PM« (der erste Eintrag) stellt ändert das nichts an dem Fehler.

Workaround: einen Draft-Artikel für jeden Tag im Voraus erstellen und diesen dann mit Deepest Sender in der Post-History editieren und speichern. Das funktioniert nämlich ohne den Fehler »Invalid date/time format«. Der Fehler scheint also damit zusammen zu hängen dass Deepest Sender das Datumsformat zum Einstellen des Datums zum Veröffentlichen nicht beherrscht – dieses wird nämlich beim Editieren vorhandener Artikel nicht mehr geändert. Nun gibt man noch auf blogger.com bei »Format des Zeitstempels« ein Format an das nur aus dem Datum besteht, und schon stört die falsche Uhrzeit bei den im Voraus erstellten Artikeln nicht mehr.

  • Man schreibe Datum und Uhrzeit des Beginns der Erstellung und der letzten Änderung (außer bei unwesentlichen Korrekturen) eines Posts mit in diesen Post. Sonst ist in den offline gespeicherten Posts nicht mehr ersichtlich wann sie erstellt wurden, außer evtl. im Dateinamen.
  • Man nehme bei der Offline-Speicherung von Posts das Datum des Beginns der Erstellung in den Dateinamen auf. Man nehme die Titel der Blog-Posts in die Dateinamen bei der Offline-Speicherung auf. Dabei nehmen man stets den ganzen Titel auf, ersetzt Leerzeichen durch Unterstriche und legt fest dass Posts eine Titellänge von max. 25 Zeichen haben dürfen.
  • Um Entwürfe zu kennzeichnen nehme man in den Dateinamen als letztes Element »DRAFT« auf.
  • Um private Posts zu kennzeichnen nehme man in den Dateinamen als letztes Element »PRIVATE« auf.
  • Man kann ein kleines Script schreiben das aus den offline gespeicherten Posts ein Buch (das eigene Tagebuch quasi) generiert.
  • Man verwende Deepest Sender auch als Browser zum Betrachten seiner privaten, nicht veröffentlichten Posts.
  • Zum effizienten Handling von Bildern und anderem verlinkten Material: man verwende einen Kommandozeilen-Befehl der eine per Argument angegebene Datei (im Format: file:///home/matthias/folder/cimg0146.jpg) sowohl in einem Materialordner speichert (ggf. mit neu anzugebendem eindeutigem Dateinamen, ggf. als symbolischer Link wenn gewünscht) in dem Ordner der den Blog offline enthält als auch per FTP in einen Ordner hochlädt und die URL zum Zugriff in die Zwischenablage von X kopiert. Das o.a. Format für Dateinamen verwendet z.B. digikam wenn man ein Bild in die Zwischenablage kopiert. Die hier vorgeschlagene Weise erzeugt zwar etwas Redundanz auf dem eigenen Rechner, aber so sind alle zum Blog gehörenden Daten zentral an einem Ort vorhanden so dass man in den offline gespeicherten Posts auch die Bilder usw. voll nutzen kann. So ergibt sich auf einfachste Art eine Download-Komponente!

Regarding the content management system Apache Lenya: Installation instructions, a little FAQ, pupularity estimation, Lenya idea blogging and a list of some Lenya bugs and flaws.

FAQ

How to install the Lenya prerequisites?

This answer deals with installing Lenya on SuSE Linux 8.1 (i386). Here, we go along the list of prerequisites for Lenya.

Java 2 Platform Standard Edition
You need a J2SE SDK (Software Development Kit), not just the J2SE JRE (Java Runtime Environment)! Note that the J2SE SDK contains a full J2SE JRE. The SDK must be from the 1.4 series, at least 1.4.1; 1.3.x or 1.5.x will not do for Tomcat 4.1.29! So check out your Java environment: rpm -qi java2. Update from Download Java 2 Platform, Standard Edition, v 1.4.2, if you need. Notes on installation:

  1. Extract the downloaded file to an RPM by executing it: bash j2sdk-1_4_2_06-linux-i586_rpm.bin.
  2. Install the RPM by “opening” the package file in kpackage, or via rpm -i j2sdk-1_4_2_06-linux-i586.rpm. The installed RPM is found in the
    RPM package hierarchy as Development::Tools::j2re, not in Development::Java as SuSE’s J2SE RPMs.
  3. No existing older J2SE package is replaced by the J2SE 1.4.2 SDK RPM package.
Tomcat 4.1.29
I used the file jakarta-tomcat-4.1.29-LE-jdk14.tar.gz. Installation instructions are found in RUNNING.txt in the un-tar’ed package. Set the JAVA_HOME environment variable with export JAVA_HOME=/usr/java/j2sdk1.4.2_06.
Apache Ant 1.6.1 or newer
I used the file apache-ant-1.6.2-bin.tar.gz. Installation instructions for this binary distribution are found on http://ant.apache.org/manual/install.html. All bash login shell configurations, such as setting PATH and ANT_HOME environment variables, are done in /etc/profile.local (for all users) resp. ~/.profile (for single users).
Apache Cocoon 2.1.4
I used the file cocoon-2.1.4-src.tar.gz. From here on and for installing Lenya itself, use Apache Lenya :: Installation of the Source Version. According to these instruction, you need two files from the Lenya source distribution, so do not download the binary one.
Endorsed Libraries
These libraries (Xalan and Xerces) are shipped with Lenya and need not be installed separately.

How to solve the error “Failed to convert address [0:0:0:0:0:0:0:1]:”?

Situation: after a fresh and successful installation of JDK, Ant, Apache, Tomcat, Cocoon and finally Lenya you want to test it by using http://localhost:8080/lenya. You get an error page saying: “An Error Occurred Failed to convert address [0:0:0:0:0:0:0:1]: org.apache.lenya.ac.AccessControlException: Failed to convert address [0:0:0:0:0:0:0:1]:”.

Direct cause: The failing function tried to convert the string “0:0:0:0:0:0:0:1” into an IP address. So, on your system the hostname “localhost” corresponds to the (IPv6 ?) string representation “0:0:0:0:0:0:0:1” which is obviously not what you want. So there’s a problem with name resolution on your machine, at least for IPv6 addresses. This is not a bug within Lenya “IP ranges” as these are for access control only, these do not define name / IP address mappings.

Solution: Use the IP-version of the above address to work around buggy name resolution:
http://127.0.0.1:8080/lenya

How do I use Lenya’s WebDAV functionality?

This is an important question. For frequent document editing, the browser based editors are not comfortable enough neither are they independent of the browser. Using e.g. Microsoft Office as a WebDAV client and provided the fact nearly every Windows PC has it installed, these disadvantages go away. With WebDAV, nobody is forced to use Mozilla for the BXE browser based XML editor.

How popular is Lenya?

The following is as of 2004-10-23. Given the fact that pages about CMS systems will share the same set of vocabulary in average, we might use a Google search for “<CMS-name> CMS” as a CMS popularity index. We add the string “CMS” to exclude pages which have the CMS’s name in another context, e.g. “Mambo” for dancing and “Lenya” as a woman’s name.

For the Mambo CMS this popularity index is about 309,000, for the Typo3 CMS about 113,000 and for the Lenya CMS about 11,800, which amounts to 3.3% of Mambo’s popularity and 10% of Typo3’s popularity. Given the fact that Lenya is in the world from 1999 on, even one year longer than e.g. Mambo, this popularity is less than expected. This might be due to the fact that Lenya is a huge-scale CMS, for professional sites, not even usaable on small webspace
packages.

Even more interesting is the fact, that Google stops after about 500 results for “Lenya CMS” and remarks that the rest is “very similiar”. That means, there is not much more about Lenya than the official pages at Apache Software Foundation and some notes in Weblogs and forums. This makes the Lenya community very “clear” structured: you know where to go for code and documentation, you need not search on hundreds of pages as it is the case with Mambo and, partially, Typo3.

List of Bugs and Todo Items

  • BXE installation misguided. The page that is shown if you try to edit a page with BXE and BXE is not yet installed is misguiding. It tells you to put the BXE tarball contents into webapps/lenya/lenya/resources/bxeng/ but there is only the directory webapps/lenya/lenya/resources/misc/bxeng/. Furthermore, the user sould be told that he will find the directory in his tomcat home directory.
  • Centralize Documentation. At the moment, there are four different documentation systems: Forrest (as a Lenya publication), Lenya API Documentation (JavaDoc), Lenya Wiki (Wiki system) and several mailing lists. The more parallel documentation systems you have, the more difficult it is to find what you look for. You might try to merge them into one system (this might include to delete messages from the mailing lists after their knowledge contributions have been included in this centralized documentation effort).
    As for the Wiki, the Lenya team already move in that direction: “More documentation (work in progress) can be found at the Cocoon Wiki. If you feel able to enhance the documentation the wiki is a good place to do so. We will integrate articles of the wiki in the documentation after reviewing them, so just start the wiki page and let us know the URL.” (from Apache Lenya Documentation, but that might be no official statement yet). Anyway, it would be nice to have all integrated in a Lenya CMS application, with different kind of status for documentation article (new, in review, included) and edited through Lenya authoring mode. It would be great if all documentation could be downloaded as one single PDF book!
    The Javadoc documentation could be integrated in the Lenya publication by writing a Javadoc doclet that produces XML output compatible with Lenya’s documentation XML format.
  • Make the developer interface clear. For a new developer, it is not clear what he can use and what he should not use: what parts of tomcat, cocoon, apt, java, xerces and xalan, XML, XLink, XSLT etc. and where to find their documentation. It would be great to provide a developer start page (as the top page of the developer’s part of the Lenya documentation) where it is clearly stated how to interface with Lenya and where all the docs are.
  • No borders in PDF generation. The PDF files for the Lenya online documentation have nopage borders. For an example, see Documentation ::
    Integrator/Dev Guide :: Components :: Editors :: Bitflux Editor
    or pdf docu (whole).
  • Flaws in generated PDF file’s table of contents. Referring, for example, to pdf docu (whole). This document has just one chapter named with the publication’s name. Instead, the publication’s name should get the title of the document. And, the table of contents lacks some levels of detail. If that
    is configurable even now, just enable it for navigating the official docs.
  • PDF generation bug: wrong heading level. Look at Documentation :: Integrator/Dev Guide :: Components :: Components: this page is content just below the “Components” section, and not content of any subsection of the “Components” section as e.g. is the case for content of the “Access Control” subsection. However, in the generated PDF, it appears in a subsection “Hello Forrest” which is at the same level with “Access Control” etc.. In such cases as for the “Hello Forrest” contents it seems that all its headings are one level to high.
  • Possibility to automatically distribute big XML files to several pages in presentation format.

Idea blogging

Architecture for extensions and dynamic elements needed

What need?In most real-life situations you need custom software to extend the functionality of a CMS. So, Lenya should provide an understandable and complete interface to do that. In more general, we need possibilities to integrate modular dynamic elements (i.e. elements that are specific for every user, like shop systems and other web applications, rather than elements that are the same for all users, like Lenya’s publications).

General conditions. First, Lenya as a CMS should not be restricted to serve “publications”, but publications shall be just one of multiple servable elements, all with the same interface. It shall be possible to have only one or more than one of these servable elements on one page, the layout being defined by a XML template.

Ideas on how to achieve. Lenya is a servlet, served by “servlet container software” such as Tomcat, Resin or Jetty. Any web application (e.g. shop systems or Cocoon-based publications as is done now) can and sould be realized as a servlet. This makes Lenya a very modular CMS, consisting just out of servlets, and a very extensible CMS, as there are many servlets that may be used or adapted. These servlets will have to output XML and provide their own XSLT (just as every publication does). Lenya, as a servlet of its own, will just be a “servlet administration interface” and not include functionality of the publication servlet any more. Every servlet must therefore provide “administration pages” through its interface that are generated as XML and transformed to the presentation format just as every other content. That way, there will be a Flash or PDF or WML Lenya as well.

No dynamic elements in publications. Publications will be a servlet administered through Lenya. Software that presents user-specific dynamic content (e.g. shop systems) will be realized as separate servlets as these things do not belong to publications. Publications may contains links to these separate servlets (as to every other part of the site), but should not include dynamic functionality theirself. The only dynamic things to to with publications are editing, publishing, deleting, scheduling etc., and that’s exactly what the authoring mode of the publication servlet is for.

Use Lenya to manage your local content and to format your publications

Lenya as CMS for your local content. As Lenya stores its contents in files rather than a database, it is a solution to manage your personal contents. Store
anything you write in XML (e.g., DocBook format). Tell Lenya that your home directory is where all the publications are, and make Lenya publications out
of all your personal XML files. Lenya will take care to provide them for you in readable formats, no manual maintenance is necessary any more.

Putting your local publications online. For personal homepages, you want to publish something you created offline rather than writing all your documents online. Thats far more comfortable as you have free choice of tools and full access to the underlying files. Using Lenya on your homepage and for your personal files, this is no problem: create your Lenya publications offline and put them online by copying the whole subtree via ftp, scp or something. And, find out if Lenya stored relevant data for this publication somewhere not in its subtree, which would be a thing to fix.

Lenya as publication formatter only. You do not need to use Lenya for your homepage (on small webspace packages you even cannot do so). Let your local Lenya installation generate the publications in their presentation format(s) (xHTML, PDF) and upload just these files to your website. Then, use another CMS with a “static content inclusion component” to present these Lenya publications online. For example, the Mambo CMS with the staticxt component is well fitting for that task even with small webspace packages.

Use DocBook XML format for larger publications

Whereever possible, we should stick to existing XML formats rather than inventing new ones. Because, the existing formats are understood by a broad variety of applications and come with a set of useful tools, e.g. the DocBook format. This is well suiting for book-like publications. To integrate it with Lenya, you need to provide the corrspondin XSLT.

CMS neutral content via XML

CMS neutral content does not mean that you need to invent a new XML format for CMS contents. Rather, whereever possible use existing formats like DocBook. It does mean, however, to provide a infrastructure definition of how contents in these formats and the accompanying XSLT and CSS must be organized to make exchange between different CMS possible.

A CMS understanding this exchange format may store its data within this format (e.g. Lenya) or convert it to a different structure (e.g. store in SQL database) or format. It only needs to guarantee that all data can be imported and exported using the exchange format.

Write a component for Mambo to use Lenya publications in XML format. It would be best to base it on the work of MOSXML, a XML Mambo variant. Ideally, MOSXML would be re-merged with Mambo in that it provides all its work as Mambo modules and components, some for the frontend and some for the backend.

Anleitung, um das Erstellen von Inhalten mit MosXML Alpha 1.1
auszuprobieren. Dies ist jedoch noch eindeutig eine Alphaversion, so
dass nicht genügend XML-Tags für einen »echten« Einsatz zur Verfügung
stehen.

Welcher Stylesheet für den eigenen UserAgent verwendet wurde, zeigt
die Adresszeile des Browsers nach Klick auf »View XSL«. Für den Browser
Konqueror ist das zum Beispiel der Standard-Stylesheet
mosxml/xslTemplates/site2xhtml/primary.xsl.

Es gibt keine »normalen« Templates mehr, sondern sie wurden ersetzt
durch mosxml/xslTemplates/, jedoch mit dem üblichen Paketformat und den
üblichen Metainfomationen von Templates. Auch werden die Templates wie
üblich über das Backend installiert und verwaltet. Erforderliche
Dateinamen sind primary.xsl, templateDetails.xml und css/stylesheet.css
(CSS ist optional).

Es dürfen nur die Tags verwendet werden, die vom XSLT Stylesheet
verarbeitet werden. Man kann eigene Stylesheets erstellen und so eigene
Tags verarbeiten, wird aber wohl mit den vorinstallierten Stylesheets
beginnen zu experimentieren. Es gibt laut Dokumentation noch keine XSD
(XML Schema Definition) der XML-Dateien, die von den XSL-Stylesheets
transformiert werden; diese werden jedoch im Beta Release folgen.

An dieser Stelle eine pragmatische Einführung in die vom Template
site2xhtml und seinen Varianten erwartete Struktur der XML-Datei. Am
besten verwendet man wohl die Beispielartikel als Tutorials, so wie sie
in der Datenbank gespeichert sind. Danach schreibt man den Text eines
Content Items als:

Zulässige Blockelemente:

  • <p>
  • <list> <listitem></listitem> </list>
  • <ol> <li></li> </ol>
  • <img>
  • <img-note>
  • <text></text> <!– ein Absatz –>

Zulässige Inline-Elemente:

  • <b> <!– synonym zu <strong> –>
  • <strong> <!– synonym zu <b> –>
  • <i>
  • <br>

Startdatum: 2005-03-25
Publikationsdatum: 2005-03-25
Versionsdatum: 2006-03-18 (für die letzte bedeutsame Änderung)