[] []
One of the most important remaining challenges is to present the information in the World Wide Web in a way, so that anyone can use it anytime, anywhere.
The language of the web, HTML, the HyperText-Markup-Language[2], has discovered some disadvantages, mostly because it has been developed from a view- and not content-oriented point of view, and its ''loose'' standard (which allows malformed markup).
This, and the lack of semantic information (exception: meta-tags), make HTML-pages not really easy to be further processed by non-human users. Additionally, these documents were meant to be interpreted by browsers running on desktop-PCs, usually equipped with large screens and ''mighty'' input devices such as mice or keyboards.
Therefore, HTML is not a device independent language - if one wishes to display web pages (written in HTML) properly on a wireless device, she will either have to enhance the mobile browser (which is often difficult, due to the possible lack of resources), invent a completely new language for the Wireless World Wide Web (such as the Wireless Markup Language, WML[3]) and redefine the existing pages in this language (so that essential functions may still be available to a mobile user), or - and this is the core of our work - convert these documents from their way from the web server to the client's user-agent (a browser, in the most cases).
Today, the Internet has not only one language anymore - much efforts have been made to improve HTML, e.g., - mostly to overcome problems caused by malformed markup - XHTML[4], the eXtensible HyperText Markup Language, a redefinition of HTML in XML, has been introduced.
XHTML was a first step, but it was still insufficient. There was general consensus that only a clear separation of content and style will meet the needs of all the new stakeholders and techniques involved - be it automated extraction of information or delivering this information to new devices or users.
The World Wide Web Consortium's (W3C) eXtensible Markup Language
(XML[5] - a strict subset of SGML[6],
the Standard Generalized Markup Language) is a
meta-language for defining new markup languages.
In the last years it has proved to be the right language not only for
the definition of standard device languages and
formats (e.g., XHTML, WML...), but also for creating all
kind of ''self-describing'' data.
Furthermore, in combination with XSL ([7]), a language for
transforming (XSL/T) and formatting (XSL:FO) objects, we now
theoretically achieved the desired separation of meaning
and view.
So, with the help of XML and XSL/T it is now possible to create different views of the same underlying content: After applying different stylesheets (e.g., one for XHTML-output, and a WML-version for WAP-browsers) to one and the same XML-data-file, we obtain several ''viewable'' versions of the (XML-)data-document - e.g. an XHTML-version for the web and a WML-page for (older) mobile browsers. This ensures homogeneity, although documents will still be published under different public (HTTP[8]) addresses (e.g. ''www.mydoc.net'' and ''wap.mydoc.net'').
For many legacy web pages which have not been created out of an XML-source-file, however, a redesign from scratch (either in the mentioned way or in a ''mobile language, such as WML) seemed to be not feasible. Therefore, the task of converting these documents ''on demand'' became more and more important.
The main idea behind this project was to dynamically transform HTML-pages to whatever format the requesting client (browser) is capable to understand. While we have originally been looking for a new way of delivering web content to wireless devices, i.e., a transparent, flexible and extensible way to transform documents written in HTML to various output-formats (e.g. XHTML or WML), we found a solution that did not only satisfy us regarding our main aim. It has also proved to be suitable for (at least some of) the requirements of many other popular questions in the emerging field of web engineering.
In the course of our work, we defined (in XML Schema[9])
two new (XML-)languages:
The first language's purpose is the inspection of HTTP-requests (what kind
of device is used, which page is requested..) and the definition
of what (i.e., if or what kind of transformation-rules should be applied
to the corresponding HTTP-response from the web server) should be done if a
web request meets certain criteria.
The other language is used for specifying how to do this transformation.
It does not not only offer possibilities to import or implement XSL- and XQuery-scripts,
also simpler search-replace- and more complex page-splitting-functionalities are
implemented in this language.
For ''common'' transformations (e.g. converting an HTML-form to a WML-form, extracting
links, and many more) we created several predefined stylesheets, so one
may not have to deal with XSL or XQuery by her own.
This layer of abstraction - and the fact that we kept those (configuration-)languages self-explaining and simple but quite ''mighty'' - not only reduces development-efforts of (either online- or realized as browser-plug-in) graphical configuration-user-interfaces, it also provides a ''self-explaining'' way to convert web content on demand.
FOXY (Filtering prOXY) works as an intermediary between (not necessarily) wireless clients and HTTP servers. It converts existing web content dynamically on demand and presents it in the most appropriate form to the (mobile) user.
This section gives a brief overview of our aims regarding technique and functionality of the prototype.
Assuming the user wishes to follow the knowledge-rich approach (i.e., she does not want the system to decide which pages should be converted), we had to find an efficient way to provide her the possibility to ''tell'' the server which pages should be transformed, i.e., what criteria an incoming HTTP-request has to meet, so that the corresponding HTTP-response data (or also the original request itself) will be modified by one ore more transformation-rules. Therefore, we compare incoming HTTP-requests with so called (HTTP-request-)patterns that are defined by the user (in the patterns configuartion file). When an HTTP-request matches a pattern (e.g. host=''www.xyz.com'', path equals ''/''), a set of transformations - or rules - are then be applied to the corresponding response of the web server (or even before - to the client's request-header). For this reason, we compare (also involving regular expressions) characteristical parts the HTTP-request, such as server, port, path, parameters and header fields to corresponding values of stored request-patterns. This makes it for example possible, to apply particular transformation-rules (or a group of them) for all requests with header field ''User-Agent'' containing the word ''WML'' or for all pages on server ''www.example.org'' in URL-path ''/news'' or for a certain page with URL-parameter ''user'' set to ''john'', to name just a few.
One of our aims regarding the prototype's implementation was to keep it as flexible as possible. Flexibility, in this case, does not only refer to the usage of the system - we also wanted the implementation following a modular approach, so that essential functional parts may be changed (either by the user himself or by one of the developers) or replaced (if e.g. a newer or better solution for a certain task exists) over time, without the need of adapting other parts of the system to these modifications. So, our first task was to split our problem (mobile web access) into pieces and to design an architecture that combines and interact between these pieces.
Our prototype implementation basically consists of three main parts:
To ensure a high degree of usage-flexibility, request-patterns and transformation-rules are stored in external files (and can be modified at server's runtime). The essential functionality of the server's ''filter''-(or transformation-, respectively) process is realized in these configuration-files. They are loaded at startup and can be changed and reloaded (separately) at runtime. Our first candidate regarding the file-format was naturally XML - it has shown to be the right language-standard for describing data and there are many free parsers and tools available that make the handling of XML-based data-structures quite convenient.
For the implementation of the server, we decided to use the Java ([10]) programming language - in the last years it has clearly proven to be a stable solution for creating object-oriented (and often distributed) network- and Internet-applications. Additionally - if we keep the format of our configuration-files in mind -, there are a large variety of HTML- and XML-parsers, XSL- or XQuery-engines, HTML-to-XHTML-converters and data-binding-utilities 2.1 available in Java.
In the next section, we describe some other tools and technologies we made use of to develop a modular and extendable prototype.
For the implementation of the prototype, we used following Open-Source ([12]) Markup-processors
This section demonstrates the server's functionality on the basis of a common connection scenario. We give a short description of some functional important classes and how they act together during the connection- and filtering-process. More detailed information about the mentioned Java-classes and packages can be found in section 2.3.2.
Figure 2.1 illustrates the stakeholders involved and the actions that have to be done, whenever a client user-agent requests a web page through the proxy server.
In the first step (1), the client sends an HTTP-request to the proxy server. An HTTP-request generally consists of one (text-)line containing the request's method (e.g. GET, HEAD, POST) and its URI, as well as an HTTP-header, which contains one or more key-value pairs, called HTTP-header fields (see figure 2.2).
In the next step (2), the server looks for a pattern that may match the client's request. A pattern is unique for every host (and port) and can include several ''sub-patterns'' for different paths on this host. To enlarge granularity and flexibility, pattern-definitions may also contain simple conditional expressions (see section 2.4.2). When the incoming request has matched a particular pattern, the PatternMatcher-component delivers back a set of transformation-rules (3). Additionally, the pattern may also include instructions for modifying the HTTP-request forwarded to the original server This is mostly needed if the client asks for content, the web server cannot deliver. In this case, we have to change the ''Content-Type''-header field to an appropriate value before delegating the request to the web server (4). All other transformations (except the redirection of requests, naturally) are done after the HTTP-server has sent back the requested content to the proxy server (5). This task involves the appliance of one or more XSL- or XQuery-stylesheets, simple search-and-replace operations or the splitting (or re-layouting) of pages. These transformation-rules may also be summarized in so-called groups. In the last step (6), the proxy server returns the transformed response-data - which may include modified header fields - back to the client,
The different types of transformations (or -rules, respectively) (I-IV) are explained in detail in the configuration-section (see section 2.4.2 and 2.4.3.
This section focuses on the software-architecture of the FOXY-system. Although an exhaustive JavaDoc-documentation is included in the (source-package of the) prototype implementation, we shortly describe some important packages and classes in the following.
http://infosys.tuwien.ac.at/foxy
This site provides various distributions (binary, source) as well as a short description of the project.
The foxy.config package consists of three sub-packages: rules, patterns and server - each one responsible for the configuration-data of the same name. The classes in the root of these sub-packages are more or less a ''Java-representation'' of the elements described in the corresponding Schema-file. From outside the package, we only have deal with these objects (named after their underlying XML-elements) and do not need to parse the configuration-files by our own.
Figure 2.5 shows an example for reading in the server's (HTTP-request-)patterns configuration file:
 |
A more detailed description of structure and usage of the configuration-files can be found in section 2.4.
This is the core package of the application. It contains the server classes as well as sub-packages for special functionalities (filter, transform, connection) which are further explained in the following sections.
ProxyServer
This class represents the server-daemon. It listens at the server's TCP-port and starts a request-handling thread (called ProxyHandler) for any incoming connection. The server is usually started via the foxy.Shell-class (the only class in the root foxy package), which provides a text-based interface to view or change server-options as well as a clean way to shutdown the server.
ProxyHandler
After a connection has been delegated to the ProxyHandler, this thread takes responsibility for the incoming request. It first tries to find a pattern-definition according to the web server's host-name defined in the request. If a pattern-definition has been found, the PatternMatcher (see below) compares the request-data to it and - if a match occurred - delivers back a set of transformation-rules. The handler-thread then contacts the web server (note: the forwarded request to this server can also be modified by the proxy) and reads in the HTTP-response. Afterwards, the transformation-process itself is done (mostly) with the help of the transform- and filter- (sub-)packages. At the end, the ProxyHandler delivers the ''filtered'' (i.e. modified) response-data back to the client and stops.
Figure 2.8 shows a simplified diagram of this process. Simplified, because it does - due to readability-reasons - neither contain representations of the filter- and transformer-classes involved in the transformation-process nor the abstractions of the HTTP-connections (interface ProxyConnection) mentioned in the foxy.proxy.connection-package (see section 2.3.2).
PatternMatcher
This class is an enhanced representation of the pattern-element in the patterns-configuration-file. A hash table of PatternMatcher-objects (unique for every host) is stored in the server's environment (class ProxyEnvironment, see section 2.3.2) to ensure a quick and efficient way to match incoming requests against stored patterns.
ProxyEnvironment
This class holds important information about the running server. This involves the definitions of rules and rule-groups (stored in hash tables), a map of PatternMatcher-objects (see @@@), information about the server's status (port..) and logger-functionality.
Once the request-/response-data is wrapped in the ProxyConnection-interface (or its implementing classes, respectively), the content is available as array of bytes and the header fields are accessible either as hash table or as pure text. A HeaderField, in FOXY, is not just a name-value-pair. To overcome problems caused by name-inconsistencies (e.g. ''User-agent'' or ''User-Agent''), we additionally store a lowercase version of the header field's name, which acts as a unique key for the field.
Figure 2.9 shows the usage of the connection-classes during a common HTTP-connection through FOXY.
Figure 2.10 shows the relation between the classes and interfaces of this package.
The structure of these classes is presented in figure 2.11.
In addition to the common filter-classes, the package contains one class that supports the completion of more complex transformations, called HTMLNodeVisitor:
HTMLNodeVisitor
This class performs page-splitting and process-partitioning tasks, respectively. It is inherited from the HTMLParser's-package (see section 2.2.2) NodeVisitor-class, which can be loosely compared to the functionality of a common SAX XML-parser's ContentHandler. When parsing an HTML-page, the parser decides (by given parameters and special group- and subgroup-tags embedded in the HTML-code) which parts of a page are left out. The remaining HTML-data is then delivered back to the client. When splitting large documents into smaller pieces, it is also possible to add different headers and footers to these pieces. The transformation-rule responsible for this process is called layoutPage, and is described further in the configuration-section (see refConfiguration)
In this section, we describe how the server's transformation and pattern-matching behavior can be customized.
FOXY is configured by three XML-files. In the following, we describe these configuration-files and their usage in detail.
Figure 2.12 shows the general structure of the server configuration file. The whole W3C XML Schema definition is shown in figure 2.13.
The server configuration file consists of following elements:
server
: This element is the root element of the server configuration file.
All other elements are children of the server-element.
It provides one attribute (port) describing the server's listening port.
logFiles: This element stores the location of the log-files-directory,
(in our example the log-files are stored in a directory named ''log'',
which path is relative to the server's home-path).
The attributes prepend and append define text that is
ap- or prepended to the name of the log file.
This file is automatically created by the server at startup (its initial name is a time
stamp in the following format: yyyy-MM-dd-HH-mm-ss-SSS).
patterns and rules: These elements contain information about
the location of the rules- and patterns configuration files explained in the
following sections (attribute fileName).
patterns-Language
The language of the patterns configuration file has been designed for specifying so-called HTTP-request-patterns, against which incoming requests are matched. This involves the examinitation and comparison of characteristical parts of the request. The patterns-language also allows simple selection constructs (if-then-else). Figure 2.16 shows a structural representation of this file's format. A complete definition of its underlying W3C XML Schema can be found in the appendix.
The main elements allowed by the W3C Schema definition of the patterns-language are defined as follows:
patterns: This element is the root element of the patterns configuration file.
It has no attribute and contains a sequence of pattern-elements
(see figure 2.15).
pattern: The attributes of this element contain information
about the host name and the port of the web server, which are compared to the
corresponding values of the client's HTTP-request in the pattern-matching process.
Wildcards for these attributes that match every host name and every port are ''*'' and ''-1'',
respectively.
The pattern-element consists of a sequence of path-elements,
which provide further examination (and comparison) of the HTTP-request (see
2.17).
path: The meaning and usage of the attributes of the path-element are
similar to the ones in the pattern-element, except that this time -
instead of the host name
- the path of the requested URI is compared to the match-attribute of the path-element.
Additionally, it provides a second (optional) attribute, named compare, which defines the type of string-comparison that should be used when trying to match the
path of the requested URI to the element's match-attribute.
The path-element has either one child - the action-element (see
2.19), or it may contain a sequence
of if-elements followed by a closing else (see figure 2.21).
action: This element (of type applySequence, see figure 2.19)
contains a sequence of transformation-rules and -rule-groups (or
their names, respectively) that should be applied to an HTTP-response after
host name, port and URI-path have successfully been matched against the
corresponding values of the pattern. This sequence is implemented as a set of text-elements,
named applyGroup and applyRuleGroup, respectively (see figure
2.19).
Possible modifications of the header fields (of the forwarded HTTP-request)
may be specified before (child-element setRequestHeaderField) the definition of
this so-called applySsequence .
Alternatively - instead of a sequence of rule-references - the
action-element may only consist of a redirect-element (see
2.20).
This is used for delegating an HTTP-request to a different location (Note: This new location
is then also compared to the available request-patterns, i.e. it will be handled in the
same way as a common client-request.
The maximum count of consecutive redirections is limited by three.).
if, then and else: The if-element,
allows it to specify particular actions for request-URIs with equal host- and pathnames, depending
on the values of certain header fields and/or URI-parameters.
These fields are compared with the help of the elements headerField and urlParameter,
that consist of a name- and a value-attribute and an optional one (compare),
responsible for the type of string-comparison (allowed types of comparison are:
equals, startsWith, endsWith, contains, matches and
containsRegExp) (see figure 2.21).
The then-element comes into action, when the values in the if-clause (i.e. particular
header fields or parameters of the request-URI) have successfully matched.
This element - as well as the else-element and the body of the
if-element - is of the same type as the action-element
(applySequence, see figure 2.19).
2.19
rules-Language
In the following, we outline the general structure of the rules configuration file. Then follows a detailed description of important language-elements.
rules: This element is the root element of the rules configuration file.
It has no attribute and contains a sequence of rule-elements and
ruleGroup-elements (see figure 2.23).
rule:
The rule-element is responsible for defining transformation-actions.
A transformation may be a simple text search-and-replace action, the appliance
of XSL- or XQuery-stylesheets or the splitting of a large web page or -form.
Therefore it can consist of a searchFor-replaceWith-element,
elements for defining or importing stylesheet-data (named xsl and xquery),
or an element that deals with the splitting and re-layouting of web content, layoutPage.
It may also contain information regarding the response header, i.e. if or how the
header of the HTTP-response should be modified. This is done with the help
of one or more setResponseHeaderField-elements at the beginning of the rule-definition
(see figure 2.24).
ruleGroup:
A ruleGroup is a sequence of references (via the rule's id-attribute)
to (previously defined) rule-elements (see figure 2.25).
With the help of this element, several common rules can be grouped and can in the following be
identified and accessed by one unique id.
searchFor and replaceWith:
This rule-type deals with simple text search-and-replace transformations.
It consists of two text-elements, called searchFor and replaceWith.
The first one defines text to be searched for, while the latter holds the text-data, the search-string
is replaced with. Common regular expressions (Java-style, similar to Perl-regular-expressions)
are accepted.
xquery and xsl:
These elements are responsible for the definition and the import of transformation-stylesheets.
Both are of type xscript (see figure 2.26).
Because HTML-content has to be converted in well-formed XML before any stylesheet can applied,
the xscript-data type provides one attribute (preTransform) to tell the system, if
the underlying data has to be ''pretty-printed'' (or ''tidied'') before the transformation process.
The body of the xsl- and xquery-elements consists of one text-element - either import, which holds the name of an external-script-file, or script, which allows
a direct in-place definition of the stylesheet in the text-content of this element (as CDATA).
Figure 2.26 shows the W3C XML Schema of the xscript-element.
layoutPage:
This element is responsible for splitting web pages and -forms and/or adding header- or footer-data to
particular pages.
When splitting a large page into smaller pieces, we achieve this by summarizing the ''interesting'' parts in groups and subgroups.
This grouping is done by adding special group- and subgroup-tags (named foxy:group and
foxy:subgroup) into the (existing) web page. This may be done dynamically (by adding the tags via a foregoing
xsl- or xquery-rule) or statically (e.g., when you are the owner of the page). A unique ID is assigned
to each group in order of appearance in the original (HTML-)content. Each subgroup has a unique ID for its group
(i.e., each first subgroup in a group has ID=1) All documents transformed via layoutPage do accept following
URI/URL-parameters:
The layoutPage-element has five (integer-)attributes, holding the values for
the first and last group-IDs and subgroup-IDs (default for all: -1) and one
for defining the default group that should be displayed, when no group-selecting parameter
has been provided:
Possible (optional) child-nodes of this element are defineTag (multiple times), header and
footer.
The header- and footer-elements are ap-/prepended to every displayed page-fragment (either a
group or a subgroup) and may help you with adding dynamic context to our transformation.
The header- and footer-scripts are either defined directly (via a script-element) or imported
from a file (similar to the xsl- and xquery-rules, see figure 2.26).
Furthermore, the user can define her own tags, e.g. to give headers of different groups a different look.
This is done by providing special-tags, which are replaced at runtime with their appropriate value. These special-tags are:
The defineTag-element, which purpose is the definition of special tags,
has following attributes:
A self-defined tag has following structure:
![\fbox{@TAGNAME[DEFAULT\_VALUE]}](../img/img21.png){kind=small}
On any other pages, the default text is used. This text is defined directly in the HTML-code.
The @welcome-tag may be implemented (e.g., in the HTML-code of the
header- or footer-element):
![\fbox{@welcome[Group @currentGroup of @lastGroup]}](../img/img23.png){kind=small}
layoutPage-element.
When requesting this page with a common desktop-browser, only the chosen menus and the login-form should be displayed to the mobile user (presented in an HTML-table), so one does not have to deal with all the news- and advertising-content of the original page. When accessed by a WAP-enabled mobile phone, however, only the site's login form should be delivered to the mobile user.
The transformation process starts by first manually inspecting the HTML code of the desired web page. Figure 3.2 depicts part of the HTML source code of the GMX web page that is of interest. Note that the menu content (i.e., ''Produkte'' - the german translation of ''product'') is enclosed by HTML list elements (i.e., <li>), each with a unique class attribute that specifies the style of the menu. The login form is implemented using HTML form elements (i.e., <form>). After the elements and patterns in the HTML source code have been identified, HTTP-request patterns can be created and fed into FOXY to initiate the transformation and adaptation action whenever the web page is requested by a specific type of user-agent.
searchFor and a replaceWith element. These elements provide text-based
search-and-replace functionality that allows the usage of regular expressions.
In our example, we need it to cut out XML-entities (&..;) that cannot
be processed by the Saxon XQuery processor.
The transformation rule called extractLoginFormAndMenus (line 5) is
defined by an xquery element. This element has one optional attribute named
preTransform (line 6). By setting it to true (which is the default value), the input
data is then considered to be not well-formed XML (i.e., HTML) and will be converted to (well-formed) XHTML content (i.e., a process often called tidying) before the XQuery stylesheet is applied.
As we did not want to implement the XQuery script directly in the rule-body, we use the
import element (i.e., import) which allows the specification of an external
XQuery stylesheet file - i.e., gmx2html-table.xql, line 7) to be imported.
The complete listing of this script can be found in the appendix (see figure A.3).
It is similar to the script used for content-adaption for mobile clients,
but it does not only deliver the login form.
In addition, it shows some ''important'' menus and produces HTML-code instead of WML-output.
The extractLoginForm-transformation-rule is also implemented as XQuery-script.
This time, the xquery element has one child named script
(e.g., lines 13-28). This element indicates that the XQuery script
is implemented directly in the rule database
The XQuery-code (lines 15-26) is implemented quite straightforward: First an HTML-form with the name ''login''
is extracted. Then it is wrapped into a WML card element and finally presented
as WML-document (wml!DOCTYPE wml...).
Because WAP browsers do check the Content-Type header field and will produce
an error message whenever HTML-content is detected, it is required to change the value
of this field to indicate that WML-content is delivered (i.e., text/vnd.wap.wml, line 11).
Figures 3.5 and 3.4 show screenshots of the transformations
as seen on a traditional browser and a WAP phone.
Suppose that the information being extracted from the web page is large
and needs to be split over a number of smaller pages. In this case, the splitting
elements foxy:group and foxy:subgroup are ''inserted'' into the extracted
content by means of XQuery or XSL instructions. The layoutPage-element can then be
used within the rule implementations to browse between the resulting page splits.
Note that in web sites which use a common layout (i.e., corporate identity),
FOXY is especially effective because the same HTTP-request pattern and transformation
rules can be applied to a large number of web pages.
 |
 |
In the example presented in the previous section, we demonstrated, how FOXY can be used to dynamically create different versions of the same web page, depending on - for example - the connecting client user-agent. In this chapter, we discuss the assets and drawbacks of our system, focused on flexibility, extensibility and maintenance costs (including learning efforts).
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.
An additional way to reduce configuration efforts is the implementation of a graphical user interface (GUI) for the configuration files, an enhancement which may be realized in the future (see section 4.4). This GUI can also include functionalities for selecting important parts of web pages for later transformation (see section 3.1.2), hence, not even basic knowledge of HTML may be required to perform transformation tasks in the future.
Additionally, to assist the user in the task of selecting important parts of a web-page, a browser-like GUI that offers facilities for selecting HTML-content in real time can be implemented (This GUI could be combined with the mentioned configuration user-interface.). It has to provide the user ways to graphically ''pick'' the parts (of a web page) of her liking directly in the browser window. For example, Firefox ([17], Mozilla's ([18]) popular web browser can be extended with add-ons. These add-ons - which add new functionality to the browser - are realized with the help of XUL ([19]), the XML User Interface Language. This seems an efficient way to combine the browser's graphical capabilities with FOXY's extraction functionality.
Another possible user interface may be be created together with the implementation of specialized pre- or post-processing modules, needed for automated content (or information, respectively) extraction tasks (see section 4.4.5).
 |
rules-Language
