A Visual Approach to Authoring XPath Expressions - CiteSeerX

Extreme Markup Languages 2001

Montréal, Québec August 14-17, 2001

A Visual Approach to Authoring XPath Expressions Mari Abe IBM, Tokyo Research Laboratory [email protected] Masahiro Hori IBM, Tokyo Research Laboratory [email protected]

Keywords: XPath; Visual representations; Tool/implementation: Metadata editor; Experiments and demos: Annotation editor

Abstract Web metadata is crucial for providing machine-understandable descriptions of Web resources, and has a number of applications such as discovery, qualification, and adaptation of Web contents. While metadata is often embedded into a target document, metadata can also be associated externally by means of an addressing scheme such as the XPath language. However, creation and modification of external metadata solely with a conventional editor is not easy because metadata authoring involves the maintenance and elaboration of addressing expressions as well as editing individual documents. The objective of this study is to advance extensibility in the design of annotation editors with particular emphasis on a visual approach to authoring XPath expressions. The key idea behind the XPath authoring process is to facilitate flexibility in the creation of XPath expressions as a result of the seamless integration of three authoring methods: instantaneous creation, context-constrained creation, and manual creation. In this paper, we briefly introduce a framework for external annotation first, and give a high-level overview of our annotation editor. The three XPath creation methods are then explained, showing examples of XPath expressions and the graphical user interface for visual authoring process. Finally, we present our annotation editor developed with the visual XPath authoring capability, and show how the annotation editor is customized for an annotation vocabulary at hand.

A Visual Approach to Authoring XPath Expressions § 1 Introduction Web metadata is crucial for providing machine-understandable descriptions of Web resources, and has a number of applications such as discovery, qualification, and adaptation of Web contents [Lassila 1998]. A remark attached to a particular portion of a document is called an annotation, and covers a broad territory in the literature. Forms of annotations can be characterized by the dimensions: whether formal or informal, and whether tacit or explicit [Marshall 1998]. Metadata that follows structural specification resides at the most formal and explicit extreme. Regarding annotation in this restricted sense, "annotation" and "metadata" are used interchangeably in this paper. While metadata is often embedded into a target document, metadata can also be associated externally by means of an addressing scheme such as the XPath language [XPath 1999]. However, creation and modification of external metadata solely with a conventional editor is not easy because metadata authoring involves the maintenance and elaboration of addressing expressions as well as editing individual documents. Configurations of annotation tools depend on the annotation scenario. Browser-based annotation tools [Denoue 2000] [Erdmann 2000] [Nagao 2001] [Sakairi 2001] are desirable when annotators are not allowed to edit target documents without document ownership. On the other hand, an annotation tool based on a WYSIWYG editor [Hori 2000b] is helpful when annotators are responsible not only for the creation of the annotations but also for the editing of the target documents. Regardless of the variety of emerging annotation tools, a significant limitation of the current annotation tools is the lack of extensibility, because the existing tools are developed solely for a particular annotation vocabulary, and provided with predefined views for the authoring. In pursuit of Web content re-purposing, content adaptation systems that adopt annotations by using XPath expressions are emerging [Hori 2000a] [WTP 2000] [Asakawa 2001] [Nagao 2001]. Addressing using XPath may require following a hierarchy of document elements from the root to a focal element for the creation of an annotation, and it is also necessary for annotator to be able to navigate from an existing annotation to another portion of an annotated document designated by a corresponding XPath expression. As a method for addressing parts of an XML document, a simple yet helpful support for XPath creation is to evaluate an XPath expression typed by a user and highlight the resulting node-set in a DOM-tree view [Fung 1999] [XPath Visualizer 2001]. Although such tools allow users to explore while finding the correct expression, the users need to have in-depth understanding of the XPath language, so that they can come up with alternative candidate expressions by themselves. The other extreme of tool support is to generate a particular type of XPath expression (such as /aaa/bbb/ccc and /html/body/ul[2]/li[2] ) automatically from a selected node in a graphical user interface. XSLT stylesheet editors often rely on this kind of automatic yet inflexible support for the creation of XPath expressions. The above two authoring methods are two extremes of XPath creation methods. The former provides full flexibility while requiring advanced understanding of the language syntax. On the other hand, the latter achieves ease of use while restricting the variety of expressions created. Besides these two methods, it would be substantially helpful for users to be provided with a method that is moderately flexible while requiring less

Extreme Markup Languages 2001

p. 1

A Visual Approach to Authoring XPath Expressions

knowledge of the expression language syntax. Since these three methods have complementary roles to each other, all three methods should be provided for an XPath authoring environment, so that full-fledged tool support can be realized for a broader range of users. The objective of this study is to pursue extensibility in the design of annotation editors with particular emphasis on a visual approach to authoring XPath expressions. The key idea behind the XPath authoring process is to enhance flexibility in the creation of XPath expressions by seamlessly integrating three authoring methods: instantaneous creation, context-constrained creation, and manual creation. In the next section, we briefly introduce a framework for external annotation and give a high-level overview of our annotation editor. Section 3 [below] explains each of the three XPath creation methods showing examples of XPath expressions and the graphical user interface for visual authoring process. Finally, we present an annotation editor developed with the XPath composer in Section 4 [below], and show how the annotation editor can be customized for an individual annotation vocabulary.

§ 2 Annotation Framework This section introduces a framework for external annotation [Hori 2000a], and draws implications for the high-level design of annotation editors from the framework. The framework of external annotation prescribes a scheme for representing annotation files and a way of associating original documents with external annotations. The basic ideas behind this framework are twofold. One is that it should not be introduced new elements or attributes into the document type definitions of the target documents to be annotated. The other is that annotations need to be created for arbitrary parts of annotated documents. Annotations can be embedded into a Web document as inline annotations. Inline annotations are often created as extra attributes of document elements. Most existing HTML browsers ignore unknown attributes added to HTML elements, without being bothered by the proprietary inline annotations. Because of its simplicity, inline annotation has been often adopted as a way of associating annotation with HTML documents [Mea 1996] [Rousseau 1999] [Erdmann 2000] [Heflin 2000]. An advantage of the inline approach is the ease of annotation maintenance without the bookkeeping task of associating annotations with their target document. The inline approach, however, requires annotators to have document ownership because annotated documents need to be modified whenever inline annotations are created or revised. The external annotation approach, on the other hand, does not suffer from these issues related to document ownership. Moreover, the most important point of the external annotation approach is that it facilitates the sharing and reuse of annotations across Web documents. Since an external annotation points to a portion of a Web document, the annotation can be shared across Web documents that have the same document fragment. Furthermore, the mixing of content and metadata is not desirable according to the design guideline that content should be separated from presentation [Style 2001]. External annotation files contain metadata that refers to a part of a document to be annotated. XPath [XPath 1999] is used to associate annotated portions of a document with annotating descriptions. Figure 1 [below] illustrates a way of associating an external description with a portion of an existing document. An annotation file refers to portions of an annotated document. A reference may point to a single element (e.g., an IMG element), or a range of elements (e.g., an H2 element and the following paragraphs). For example, /HTML/BODY/P[3] points to the third P element of the BODY element of the annotated document. If a target element has an id attribute, the attribute can be used for direct addressing without the need for a long path expression.

Extreme Markup Languages 2001

p. 2

A Visual Approach to Authoring XPath Expressions

Figure 1: Framework for external annotation

When annotation files are stored in a repository, an appropriate annotation file for a Web document needs to be selected dynamically from the repository either implicitly by means of a structural analysis of the subject document, or explicitly by means of a reference contained in the subject document or some other association database. The explicit association, for example, can be done by using XLink [XLink 2000] or the link tag [HTML 1999]. An annotation framework in a broader sense needs to prescribe ways of storing and restoring annotations between the annotation repository and the authoring tool. However, the repository issue is outside the scope of this study because we are pursuing a framework for annotation editors that can be customized for different vocabularies and forms of annotations. The framework for external annotation implies a high-level design of annotation editors. It is assumed here that the creation of an annotation document is a primary task of users, and the users are not allowed to modify a target document in parallel with the annotation document. In addition to the annotation document, the users need to create an addressing expression, namely, an XPath expression that points to a portion of the target document. Taking account of these assumptions, annotation editors would fundamentally consist of an annotation document editor, a target document viewer, and an XPath composer. The important point here is that the external association between documents is a constraint enforced by the annotation editor during the authoring process. Since the external annotation can be imported into a target document and stored as an internal annotation, the annotations in a repository do not necessarily have to be provided in an external form. This capability for importing external annotations is further explained in Section 4 [below].

Extreme Markup Languages 2001

p. 3

A Visual Approach to Authoring XPath Expressions

Figure 2: High-level configuration of an annotation editor

One annotation vocabulary would not fit for all the requirements of metadata representation. Moreover, it is also impractical to expect to provide a common basis for a generic portion covering all annotation vocabularies. This difficulty comes from the approach of defining document type specifications based on the grammatical aspects of specific vocabularies, because the same contents may be described with different grammars. Therefore, in order to clarify the edit-time constraints, it is important to characterize a class of annotation documents, without regard to rigorous grammatical definitions. On the basis of the properties of well-formed XML documents defined in the XML Information Set [InfoSet 2001], this study assumes an information set for annotation documents, which has the following properties. 1. A description element is an element item. 2. An XPath attribute is an attribute item, and may take an XPath expression as its value. 3. An XPath attribute is owned by a description element (owner description). 4. The parent of a description element is a document item (owner annotation document). In the above properties, the terms in bold face are information items defined in the XML Information Set, and the terms in italic are proprietary to the annotation information set. The terms with underlines are property names. Figure 3 [below] shows an RDF graph [RDF 1999] for the above definition of annotation documents based on the XML Information Set elaborated from the primitives of RDF Schema [RDFS 2000]. The information set for annotation documents clarifies the assumption made by the annotation editor. Annotation editors can be designed, so that annotation vocabularies can be dealt with consistently as long as a vocabulary meets the edit-time constraints. The annotation editor presented in Section 4 [below] incorporates the specifications of the annotation information set into an annotation profile. In the next section, the XPath composer is explained as one of the three components of the annotation editor (Figure 2 [above]), and the other two components will be briefly introduced in Section 4 [below].

Extreme Markup Languages 2001

p. 4

A Visual Approach to Authoring XPath Expressions

Figure 3: Information items and properties for annotation documents

§ 3 Composition of XPath Expressions An overview of the XPath composer is shown in Figure 4 [below]. The visual composer holds a visual presentation of a document, which is usually given as a tree view, but is not limited to a tree view as long as the view allows users to select a node or a set of nodes interactively. This section explains the features of the XPath composer on the basis of a tree view of a target document solely to simplify the explanation.

Extreme Markup Languages 2001

p. 5

A Visual Approach to Authoring XPath Expressions

Figure 4: XPath composer

The composer provides three methods for the XPath authoring: instantaneous creation, context-constrained creation, and manual creation. Figure 5 [below] depicts the three authoring methods from the perspective of the user's operations, with indication on a screen copy of the XPath composer which is a part of the annotation editor. The easiest way of generating XPath expression is to just select a node or a set of nodes in a tree view [Figure 5 [below](a)], and an XPath expression is created automatically according to a default expression pattern, and stored internally as the current expression. Some flexibility is given to users by means of the context-constrained creation method [Figure 5 [below](b)], which allows users to select a pattern of XPath expressions with the associated parameters as required by using a cascading popup menu. Although the composition by the above two methods can be completed solely by selecting nodes or menu items, these methods cannot create arbitrary XPath expressions. For this reason, any XPath expression can be manually entered as a text string in the input field [Figure 5 [below](c)].

Figure 5: User interfaces for the XPath authoring methods

Once the current expression has been determined by an authoring method, the text representation of the current expression appears in the edit field. Each node resulting from the expression is also listed in the list box beneath the edit field [Figure 6 [below](a)], and also highlighted on the tree view in the left [Figure 6 [below](b)]. This immediate visual feedback allows users to revise the current expression by either changing the selection in the tree view or editing the expression in the edit field. In this way, each of the three authoring methods can be employed in an arbitrary order in the composer. The three authoring methods are further explained in the following subsections.

Extreme Markup Languages 2001

p. 6

A Visual Approach to Authoring XPath Expressions

Figure 6: Visualization of a node set resulting from an XPath expression

3.1 Instantaneous Creation This method allows users to create an XPath expression, solely by selecting a node or a set of nodes to be pointed at by the expression. For the use of this method, users do not have to know the syntax of the XPath language at all, and an expression is automatically generated on the basis of a default pattern [Figure 4 [above](a)]. Therefore, XPath expressions created by this method will point to the same node set as indicated by the users' selection. Currently, the XPath composer provides two types of expressions that can be used as a default expression. One is to create an expression that points to elements of a target document using a sequence of child-position location steps (ChildPosSeq). Another is an expression that points to elements by means of a descendant position (DescendantPos). The composer allows setting one of these types of expressions as a default pattern. A couple of expressions are given below as examples. A simple XML document is used as a target document, whose root element is "products", which includes five "item" elements (Figure 7 [below]). When a user selects a single element in the user interface of the XPath composer [Figure 5 [above] (a)], one of the following expressions is generated on the basis of the setting for the default pattern, and the current XPath expression is set to the resulting expression. For example, as a result of selecting the second "item" element in Figure 7 [below], here are the XPath expressions that could be generated: • •

ChildPosSeq (single selection): /products[1]/item[2] DescendantPos (single selection): /descendant::item[2]

When a user selects multiple elements, for example the first two child elements of "products" in Figure 7 [below], the following expressions could be generated simply by concatenating the expressions corresponding to single selections using the union operators. • •

ChildPosSeq (multiple selection): /products[1]/item[1] | /products[1]/item[2] DescendantPos (multiple selection): /descendant::item[1] | /descendant::item[2]



Extreme Markup Languages 2001

p. 7

A Visual Approach to Authoring XPath Expressions

pocket calculator 349.99 abacus 99.99 photo 100 New! oil painting 999 New! watercolor 109.99

Figure 7: Example: target document

3.2 Context-Constrained Creation The instantaneous creation method mentioned above does not require any knowledge about the XPath language, and an expression is automatically generated in accordance with the user's selection of elements in the document-tree view. However, this convenience is achieved by losing the flexibility of the XPath language. The second authoring method, namely, the context-constrained creation method is provided for alleviating this limitation, and give users access to the current choices for XPath expressions through a context-sensitive popup menu [Figure 5 [above](b)]. The moderate flexibility of this method uses alternative predicate expressions and addressing in relation to an anchor node. 3.2.1 Alternative Predicate Expression This kind of expression involves selecting any element that has a designated tag name and satisfies a predicate. This type of selection is expressed as "/descendant-or-self::node()/child::QName[Pred]", where QName is a qualified name given as a node test, and Pred is a predicate expression. This expression can be abbreviated as "//QName[Pred]", and this shorthand form is used by the composer. The composer currently supports two types of predicate expressions: one is to check a particular attribute value (AttrValueMatch), and another is to check the inclusion of a particular text string (StringTextInclusion). Examples of XPath expressions with this pattern are given below for each type of predicate expressions. The sample XML document (Figure 7 [above]) is again taken as the target document. If a user moves the mouse cursor to the first "item" element and clicks the right mouse button, a popup menu appears (Figure 8 [below]). The popup menu includes menu items

Extreme Markup Languages 2001

p. 8

A Visual Approach to Authoring XPath Expressions

whose labels are "by child position sequence", "by descendant position", and "by attribute value". The first two items correspond respectively to ChildPosSeq and DescendantPos as mentioned above. Since the first "item" element has two attributes, the XPath composer displays an additional submenu if "by attribute value" is selected with a right mouse button click (Figure 8 [below]). The submenu shows the two pairs of attributes and values associated with the first "item" element. If the user selects the item "category=business" in the submenu, the following XPath expression is created by the composer, and becomes the current expression. •

AttrValueMatch: //item[@category='business']

Figure 8: Submenu for creating an XPath expression by an attribute value

It must be noted here that the above expression points to every "item" element that has attribute "category" with value "business." Therefore, the node set resulting from the above expression consists of not only the first "item", which was initially selected, but also the second "item", which also has the same attribute-value pair in the sample document (see also Figure 6 [above], whose display corresponds to this situation). This is different from the instantaneous creation method that generates an XPath expression automatically without users' intervention. The instantaneous creation needs to come up with a node set that is exactly the same as the users' currently selected nodes in the document-tree view. The context-constrained creation method, on the other hand, is conducted more interactively relying on the user's decisions on the expression patterns. The visual feedback provided by the composer is thus crucial for the context-constrained creation and also for the manual creation method explained later in this section. Besides attribute value matching, text string inclusion is the other type of predicate expression currently supported for the context-constrained creation method. For example, a user can select the text content "abacus" contained in the "name" element, whose parent is the second "item" element in the same document (Figure 7 [above]). By clicking the right mouse button, the user brings up a popup menu including the choice "by text string". Since the selected element does not have any attribute, the popup menu does not display the menu item "by attribute value" mentioned above. If the user chooses the "by text string" item, the following XPath expression is created. •

TextStringInclusion (for a text node): //text()[contains(., 'New!')]

In a similar manner, if a user select a comment node such as "" contained in the first "item" element (Figure 7 [above]), the following expression is created for the comment node.

Extreme Markup Languages 2001

p. 9

A Visual Approach to Authoring XPath Expressions

•

TextStringInclusion (for a comment node): //comment()[contains(., ' on sale ')]

Note that, as in the case of attribute value matching, the above expressions could apply to other nodes that were not explicitly selected by the user, as long as they satisfy the designated predicate expression. 3.2.2 Relative Addressing Although the expression patterns introduced so far point directly to a node or a set of nodes, it is often useful for XPath expressions to refer to the surrounding context. For example, even if the location of a target element is not always stable, and often changes due to updates of the document, it is possible to create an XPath expression that relies on another element, which can be located reliably and is located near the target location. This type of selection can be expressed as "//AnchorExp/AxisName::QName[PosNum]", where AnchorExp is an anchor expression, AxisName is an axis name taken as a relative direction from an anchor node to the target node, QName is a qualified name of a target node, and PosNum is a position number that points to the target node along AxisName. AnchorExp is an expression that needs to be created first, by either the instantaneous creation or the context-constrained creation method. It must be noted here that since the relative addressing is itself a type of the context-constrained creation, an XPath expression created by the relative addressing method can also recursively be the anchor expression of another relative addressing expression. Once a node is marked as an anchor, a small flag on the node icon indicates this status [Figure 9 [below](a)]. Again using the sample document shown in Figure 7 [above], a user can select a comment node "", and create an expression //comment()[contains(., ' not available ')] , by using the string text inclusion method. In order to use the relative addressing method, the comment node can be marked as an anchor node [Figure 9 [below](a)], and then the user needs to select a target node, for example, the third "item" element can be selected as shown in Figure 9 [below](b). Clicking the right mouse button brings up the popup menu, and the user can select the menu item labeled "by relative addressing" [Figure 9 [below](c)], which is a menu item that appears only when an anchor node is marked. If the user chooses the menu item "by relative addressing" from the popup menu, the following expression is generated on the basis of the anchor expression. •

RelativeAddressing: //comment()[contains(., ' not available ')]/parent::item[1]

This expression points to the "item" element that is the first parent of the comment node(s) containing the "not available" string.

Extreme Markup Languages 2001

p. 10

A Visual Approach to Authoring XPath Expressions

Figure 9: Menu selection for the relative addressing method

When the "by relative addressing" menu item is chosen, the XPath composer determines an axis name out of child, descendant, parent, ancestor, preceding-sibling, preceding, following-sibling and following. Note that the descendant, ancestor, preceding, and following axes are sufficient to cover all the possible node positions (except for attribute and namespace nodes) in relation to a current node. However, the child, parent, preceding-sibling, and following-sibling axes are also considered here because they effectively delimit the scope of the nodes and allow for providing robust position numbers that are less influenced by changes in the document structure.

3.3 Manual Creation The instantaneous and context-constrained creation methods provide tool support for the creation of XPath expressions. Although these methods do not cover all the syntactic variations of the XPath language, the manual creation method allows users to further customize the expressions created by the other methods. The manual creation method requires that users have knowledge of XPath syntax, and allows them to directly modify the expression in the edit field [Figure 5 [above](c)]. For example, when a user creates an expression /products[1]/item[2] using the instantaneous creation method, the expression appears in the edit field. Although the expression only points to the "item" element that is the child of the first "products" element, the user can modify the predicate expression as follows, so that the entire expression can point to any "item" elements that is located at an odd position number. /products[1]/item[position() mod 2 = 1]

As an another example, after a user creates the expression /products[1]/item[2]/price[1] using the instantaneous creation method, the user can

modify the second location step and the last predicate expression as follows, so that the expression will point to all the "price" elements whose text content is a number less than 200. /products[1]/item/price[number(text()) < 200]

As a complete integrated environment, the XPath composer provides an instantaneous creation method that does not require any knowledge about the XPath language, and

Extreme Markup Languages 2001

p. 11

A Visual Approach to Authoring XPath Expressions

context-constrained creation method that allows interactive composition of expressions without any typing. These two methods allows users to easily come up with many typical expressions. In addition, the manual creation method is available for the further customization of expressions created by the other two methods. Although manual creation requires understanding of the XPath syntax, this method can fully exploit the expressive power of the XPath language. To put it another way, the flexibility of this XPath authoring environment is realized as a result of the seamless integration of the three methods: the instantaneous creation, context-constrained creation, and manual creation.

§ 4 Annotation Editor A prototype of an annotation editor has been developed with Java (JDK 1.3) according to the high-level configuration shown in Figure 2 [above]. In this section, the design of the annotation editor is introduced briefly, and how to use the editor is explained based on a scenario of creating an annotation document. Figure 10 [below] shows the constituents of the annotation editor, which are derived from the high-level configuration (Figure 2 [above]).

Figure 10: Constituents of the annotation editor

The core part of the annotation editor is independent of any particular views, and prescribes the internal document models and their relations. TargetDocument in the target document viewer and AnnotDocument in the annotation document viewer respectively corresponds to a DOM [DOM 1998] for each document. AnnotProfile in the annotation document editor is to prescribe an annotation profile, which is partly described as the annotation information set in Section 2 [above]. The XPath composer in Figure 10 [above] provides utility functions to be exploited for the visual composition explained in Section 3 [above]. In addition, the lower half of Figure 10 [above] provides customized views and an import procedure. This portion of the annotation editor depends on

Extreme Markup Languages 2001

p. 12

A Visual Approach to Authoring XPath Expressions

individual views and a particular annotation vocabulary.

Figure 11: Screen copy of the annotation editor

Figure 11 [above] shows a screen copy of the annotation editor. The main window is divided into two panels. The left pane [Figure 11 [above](a)] is the area for the target document viewer, and also contains a target view and a source view in the tabbed pane. The right pane [Figure 11 [above](b)] is for the annotation document editor containing a tree view. Note that the XPath viewer in the right tabbed pane was selected and brought up to the front while the XPath composer was explained in the previous section. When the target is an HTML document, users can employ the browser view [Figure 11 [above](b)]. The browser view is not embedded in the split pane because it is often helpful for users to compare the selection between the target tree view and the browser view.

4.1 Customization of Annotation Editor Before starting the creation of annotations, the annotation editor can be customized for a particular annotation vocabulary by selecting one of the annotation profiles provided with the editor. The profile selection dialog is shown in Figure 12 [below]. When a profile is selected from the pull-down list, the dialog shows the definition of the current profile. An annotation profile includes the location of a DTD file, an annotation file type, the location of a data directory, and the names of the information items shown in Figure 3 [above]. In the figure, the "EML Sample Annotation" profile is selected, and the annotation documents are characterized in terms of the root element name "annot", the annotation description name "description", and the XPath attribute name "target". The annotation editor assumes that a "target" attribute is owned by a "descriptions" element that is an immediate child of the root element (see also Figure 3 [above]).

Extreme Markup Languages 2001

p. 13

A Visual Approach to Authoring XPath Expressions

Figure 12: Dialog for selecting an annotation profile

4.2 Creation of Annotation The annotation editor allows users to create annotations either from scratch or from an existing annotation file. In the tree view of a target document [Figure 11 [above](a)], a check mark ('x') is added to the folder icon if there is at least one annotation description that points to the element. In the tree view of an annotation document [Figure 11 [above](b)], if an annotation description does not have any annotating node in the current target document, a question mark ('?') is added to the folder icon of the description element. In addition, users can navigate by following the external associations made by XPath expressions. When a description element is selected in the annotation tree view, the user can click a button on the toolbar to highlight annotated nodes in the target tree view. In the same manner, when a node is selected in the target tree view, a user can click another button on the toolbar to highlight description elements that are annotating the

Extreme Markup Languages 2001

p. 14

A Visual Approach to Authoring XPath Expressions

selected node. In order to create an annotation description, an XPath expression needs to be generated first using the XPath authoring methods explained earlier. Based on the current XPath expression created by the composer, the target nodes resulting from the expression are highlighted in the target tree view [Figure 13 [below](a)]. If the user clicks the toolbar button for creating an annotation description [Figure 13 [below](b)], a folder icon corresponding to the new description appears in the annotation tree view [Figure 13 [below](c)].

Figure 13: Creation of an annotation description

If a user needs to revise an XPath expression for an existing annotation description, the folder icon of the description needs to be selected first in the annotation tree view. From that point, the steps for the XPath revision of an existing description are the same as for the XPath creation of a new description. For example, if a user selects the second description node with a question mark in the annotation tree view (Figure 13 [above]) and clicks the toolbar button for highlighting annotated nodes in the target tree view, the user can choose one of the alternative authoring methods from a popup menu, which appears after clicking on the highlighted target node. The XPath expression of the second description node is then changed when the user actually chooses a menu item from the popup menu (e.g., Figure 8 [above]). As a result, the question mark on the second description disappears, because now the description actually has at least one annotating node in the target document. In this way, the XPath composition capability of the annotation editor is realized on the basis of the annotation information set explained in Section 2 [above]. Therefore, the same XPath authoring methods can be exploited for all annotation vocabularies as long as they are compliant with the data model prescribed by the information set. In addition to XPath composition, annotation authoring needs to be done on the contents of the description item. This part of authoring relies on a DTD given with a corresponding annotation profile (Figure 12 [above]). The contents of the description item can be edited in the same manner as with a DTD-based structure editor on a DOM-tree view. When a description node is selected in the annotation tree view, a popup menu can be brought up by clicking the right mouse button (Figure 14 [below]). The first popup menu is common to all annotation vocabularies, and provides menu items to add/remove an element, add/remove an attribute, and edit an attribute value. The second-level menus are derived from the DTD information of the current profile. Figure 14 [below] shows a popup menu that appears after choosing the "Add the first child element" item, and the valid elements such as "importance", "date", and "author" are given as candidates for the insertion as a child of the description node. When the user

Extreme Markup Languages 2001

p. 15

A Visual Approach to Authoring XPath Expressions

chooses the "author" item, a dialog appears with an edit field for typing the text content, namely, an author name.

Figure 14: Popup menu for editing an annotation description

4.3 Serialization of Annotation When annotations have been created, the user can save the annotation document in two ways, either as an external annotation file or as an imported annotation file. The serialization as an external annotation file can be done by simply choosing "Save" menu item from "File" pull-down menu of the annotation document editor. For example, an excerpt of the above mentioned annotation descriptions would be stored as the following annotation document: Mari Abe 2001/04/01

In addition, the created annotations can be imported into a target document, by

Extreme Markup Languages 2001

p. 16

A Visual Approach to Authoring XPath Expressions

choosing "Import" menu item from the "File" menu of the annotation document editor. The "Import" menu item is enabled only when an import procedure is given as an implementation of "AnnotImporter" Java interface. Availability of an import procedure is also specified in an annotation profile, although it is not shown in the profile selection dialog. Therefore, the methods of importing annotation descriptions into a target document can be defined according to the application-specific requirements. For example, comment sharing in a collaborative environment is being pursued in the Annotea project [Annotea 2001]. Annotations in Annotea are embedded in target documents, and XPointer [XPointer 2001] is used for locating the annotations in the annotated document. If an importing procedure is implemented in accordance with the requirements of Annotea, the sample annotations created in the previous subsection could be imported into a part of the HTML document as follows.

In the above document fragment, the elements and attributes embedded in the document are shown in bold. For example, an annotation reference in Annotea is done by using an XPointer expression xpointer(id("Mari Abe")/SPAN[2]) , which points to the SPAN element that is the second child of the element uniquely identified by the id attribute value "Mari Abe". This is a case when annotation serialization is done in the form of an embedded annotation. However, it is important to note that the annotation authoring in itself is done on the basis of the external annotation framework, and the users can have the benefits of flexibility in the metadata authoring. Annotations, especially the XPath expressions, need to be adjusted to the changes in target documents. However, it is often difficult to create XPath expressions that will correctly point at the same targets regardless of the revisions of the document. This is the issue related to robust positioning, which has been investigated through empirical studies [Phelps 2000] [Brush 2001]. However, little study has been done regarding the robustness of XPath expressions for pointing at nodes within Web documents. Therefore, we are going to investigate this issue further, taking account of real-life Web documents that develop over time, and draw practical implications to the usage and authoring process of XPath expressions.

Bibliography [Annotea 2001] Annotea Project. http://www.w3.org/2001/Annotea

(2001).

[Asakawa 2001] Asakawa, C. and Takagi, H.: Transcoding system for non-visual Web access (2): annotation-based transcoding. Sixteenth International Conference on Technologies and Persons with Disabilities (CSUN2001) (2001). [Brush 2001] Brush, A. J., Bargeron, D., Gupta, A., and Cadiz, J. J.: Robust annotation positioning in digital documents. Proceedings of the 2001 ACM Conference on Human Factors in Computing Systems (CHI 2001), Seattle, Washington (to appear). [Denoue 2000] Denoue, L. and Vignollet, L.: An annotation tool for Web browsers and its applications to information retrieval. Proceedings of the 6th Conference on

Extreme Markup Languages 2001

p. 17

A Visual Approach to Authoring XPath Expressions

Content-Based Multimedia Information Access (RIAO 2000) , Paris, France (2000). [DOM 1998] Document Object Model (DOM) Level 1 Specification Version 1.0. W3C Recommendation, http://www.w3.org/TR/REC-DOM-Level-1/ (1998). [Erdmann 2000] Erdmann, M., Maedche, A., Schnurr, H.-P., and Staab, S.: From manual to semi-automatic semantic annotation: about ontology-based text annotation tools. Proceedings of the COLING 2000 Workshop on Semantic Annotation and Intelligent Content, Luxembourg (2000). [Fung 1999] Fung, K. Y.: A visualization tool for XPath. http://xml.coverpages.org/xpathVisual19991215.html (1999). [Heflin 2000] Heflin, J. and Hendler, J.: Semantic interoperability on the Web. Proceedings of Extreme Markup Languages 2000, pp. 111-120 (2000). [Hori 2000a] Hori, M., Kondoh, G., Ono, K., Hirose, S., and Singhal, S.: Annotation-based Web content transcoding. Proceedings of the 9th International World Wide Web Conference (WWW9), pp. 197-211, Amsterdam, Netherlands (2000). [Hori 2000b] Hori, M., Ono, K., Kondo, G., and Singhal, S.: Authoring tool for Web content transcoding. Markup Languages: Theory & Practice, Vol. 2, No. 1, pp. 81-106 (2000). [HTML 1999] HTML 4.01 Specification. W3C Recommendation, http://www.w3.org/TR/html401/ (1999). [InfoSet 2001] XML Information Set. W3C Candidate Recommendation, http://www.w3.org/TR/xml-infoset (05/2001). [Lassila 1998] Lassila, O.: Web metadata: a matter of semantics. IEEE Internet Computing, Vol. 2, No. 4, pp. 30-37 (1998). [Marshall 1998] Marshall, C. C.: Toward an ecology of hypertext annotation. Proceedings of the 9th ACM Conference on Hypertext and Hypermedia, Pittsburgh, PA, pp.40-49 (1998). [Mea 1996] Mea, V. D., Beltrami, C. A., Roberto, V., and Brunato, D.: HTML generation and semantic markup for telepathology. Proceedings of the 5th International World Wide Web Conference (WWW5), pp. 1085-1094, Paris, France (1996). [Nagao 2001] Nagao, K., Shirai, Y., and Kevin, S.: Semantic annotation and transcoding: making Web content more accessible. IEEE Multimedia, Vol. 8, No. 2, pp. 69-81 (2001). [Phelps 2000] Phelps, T. A. and Wilensky, R.: Robust intra-document locations. Proceedings of the 9th International World Wide Web Conference (WWW9), pp. 105-118, Amsterdam, Netherlands (2000). [RDF 1999] Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation, http://www.w3.org/TR/REC-rdf-syntax/ (02/1999). [RDFS 2000] Resource Description Framework (RDF) Schema Specification 1.0. W3C Candidate Recommendation, http://www.w3.org/TR/rdf-schema/ (03/2000). [Rousseau 1999] Rousseau, F., Macias, J. A., de Lima, J. V., and Duda, A.: User adaptable multimedia presentations for the World Wide Web. Proceedings of the 8th International World Wide Web Conference (WWW8), pp. 195-212, Toronto, Canada

Extreme Markup Languages 2001

p. 18

A Visual Approach to Authoring XPath Expressions

(1999). [Sakairi 2001] Sakairi, T. and Takagi, H.: An annotation editor for non-visual Web access. Proceedings of the 9th International Conference on Human-Computer Interaction (HCI International 2001), New Orleans, LA (to appear). [Style 2001] Style Sheets Activity Statement. W3C User Interface Domain Activity Statement, http://www.w3.org/Style/Activity (2001). [WTP 2000] IBM WebSphere Transcoding Publisher Version 3.5 Developer's Guide. IBM Corp. (2000). [XLink 2000] XML Linking Language (XLink) Version 1.0. W3C Proposed Recommendation, http://www.w3.org/TR/xlink/ (2000). [XPath 1999] XML Path Language (XPath) Version 1.0. W3C Recommendation, http://www.w3.org/TR/xpath (11/1999). [XPath Visualizer 2001] The XPath Visualizer Version 1.3. VBXML, http://www.vbxml.com/xpathvisualizer (2001). [XPointer 2001] XML Pointer Language (XPointer) Version 1.0. W3C Working Draft, http://www.w3.org/TR/xptr (01/2001). [XSLT 1999] XSL Transformations (XSLT) Version 1.0. W3C Recommendation, http://www.w3.org/TR/xslt (11/1999).

Extreme Markup Languages 2001 Montréal, Québec, August 14-17, 2001 This paper produced from XML source via XSL, Saxon and Apache FOP Mulberry Technologies, Inc., August 2001

Extreme Markup Languages 2001

p. 19