One of the main aims of our prototype implementation was to summarize the advantages of generally accepted approaches. Some of the solutions we investigated offered possibilities to create static profiles for each device and content, some were only concentrated on one particular (mobile) output-format (e.g., CHTML or WML) while others (the earlier ones) did only provide HTML-to-HTML conversion.

We decided to create our system ''content-type independent'', i.e., we handle all text data in the same way and do only differentiate between well-formed XML (e.g., XHTML) and non-XML-conform content (HTML, in most cases). Conversions from one content-type to another are done by stylesheets defined in standard transformation-languages, notably XSL and XQuery. To avoid inconsistencies between the content-type and the corresponding field of the HTTP-header, we provide facilities to change the header fields of the client's request and the server's response, respectively. This ensures a high degree of flexibility, although the efforts of maintaining the system include the knowledge of at least one transformation-language and the basics of the HTTP-protocol. These issues are further discussed in the next section (see section 4.2).

Furthermore, FOXY offers the possibility to change or to customize certain parts of the system, e.g. to use own implementations of transformation-, filter-, or stylesheet-processing engines. So, one may use a different XSL-processor than Xalan or replace the default XQuery engine (Saxon) with one that may be more suitable for her needs.

root 2006-05-22