File:  [mozdev] / books / www / chapters / ch10.html
Revision 1.5: download - view: text, annotated - select for diffs - revision graph
Thu Oct 3 19:20:52 2002 UTC (17 years, 9 months ago) by david
Branches: MAIN
CVS tags: HEAD
updating user notes

    1: <HTML>
    2: <HEAD><TITLE>Chapter 10</TITLE></HEAD><BODY BGCOLOR=WHITE><H2>Chapter 10</H2>
    3: <H1><A NAME="77061"></A> RDF, RDF Tools, and the Content Model</H1>
    4: <P><A HREF="ch09.html#77034">Chapter 9</A> introduced the Resource Description Framework (RDF) as the basis for building display data in the 
    5: interface, where XUL templates take RDF-based data and transform it into regular widgets. But RDF is used in many other more subtle ways in Mozilla. In fact, it is the technology Mozilla uses for much of its own internal data handling and manipulation.
    6: <P>RDF is, as its name suggests, a framework for integrating many types of data that go into the browser, including bookmarks, mail messages, user profiles, IRC channels, new Mozilla applications, and your collection of sidebar tabs. All these items are sets of data that RDF represents and incorporates into the browser consistently. RDF is used prolifically in Mozilla, which is why this chapter is so dense.
    7: <P>This chapter introduces RDF, provides some detail about how Mozilla uses RDF for its own purposes, and describes the RDF tools that are available on the Mozilla platform. The chapter includes information on special JavaScript libraries that make RDF processing much easier, and on the use of RDF in manifests to represent JAR file contents and cross-platform installation archives to Mozilla.
    8: <P>Once you understand the concepts in this chapter, you can make better use of data and metadata in your own application development.
    9: <H2><A NAME="77062"></A> RDF Basics</H2>
   10: <P>RDF has two <!--INDEX RDF (Resource Description Framework):overview -->  parts: the <I>RDF Data Model</I> and the <I>RDF Syntax</I> (or Grammar). The RDF Data Model is a graph with nodes and arcs, much like other data graphs. More specifically, it's a <I>labeled-directed</I> graph. All nodes and arcs have some type of label (i.e., an identifier) on them, and arcs point only in one direction.
   11: <P>The RDF Syntax determines how the RDF Data Model is represented, typically as a special kind of XML. Most XML specifications define data in a tree-like model, such as XUL and XBL. But the RDF Data Model cannot be represented in a true tree-like structure, so the RDF/XML syntax includes properties that allow you to represent the same data in more than one way: elements can appear in different orders but mean the same thing, the same data can be represented as a child element or as a parent attribute, and data have indirect meanings. The meaning is not inherent in the structure of the RDF/XML itself; only the relationships are inherent. Thus, an RDF processor must make sense of the represented RDF data. Fortunately, an excellent RDF processor is integrated into Mozilla.
   12: <H3><A NAME="77063"></A> RDF Data Model</H3>
   13: <P>Three  <!--INDEX RDF (Resource Description Framework):data model -->  <!--INDEX data model (RDF) --> different types of RDF objects are the basis for all other RDF concepts: <I>resources</I>, <I>properties</I>, and <I>statements</I>. Resources  <!--INDEX resources:RDF --> are any type of data described by RDF. Just as an English sentence is comprised of subjects and objects, the resources described in RDF are typically subjects and objects of RDF statements. Consider this example:
   14: <BLOCKQUOTE>Eric wrote a book.</BLOCKQUOTE>
   15: <P><I>Eric</I> is the subject of this statement, and would probably be an RDF resource in an RDF statement. <I>A book</I>, the object, might also be a resource because it represents something about which we might want to say more in RDF-for example, the book is a computer book or the book sells for twenty dollars. A property  <!--INDEX properties:RDF --> is a characteristic of a resource and might have a relationship to other resources. In the example, the book was written by Eric. In the context of RDF, <I>wrote</I> is a property of the <I>Eric</I> resource. An RDF statement is a resource, a property, and another resource grouped together. Our example, made into an RDF statement, might look like this:
   16: <BLOCKQUOTE>(Eric) wrote (a book)</BLOCKQUOTE>
   17: <P>Joining RDF statements makes an entire RDF graph.
   19: <P>We are describing the RDF data model here, not the RDF syntax. The RDF syntax uses XML to describe RDF statements and the relationship of resources.<P></BLOCKQUOTE>
   20: <P>As mentioned in the introduction, the RDF content model is a <I> <!--INDEX labeled-directed graphs (RDF) --> labeled-directed </I>graph, which means that all relationships expressed in the graph are unidirectional, as displayed in <A HREF="#77002">Figure 10-1</A>.
   21: <P><CENTER><IMG SRC="foo.gif"></CENTER>
   22: <P><I>Figure 10-1: <A NAME="77002"></A></I>
   23: <I>Simple labeled-directed graph</I>
   25: <P>A resource can contain either a URI or a literal. The root resource might have a  <!--INDEX URIs (Universal Resource Identifiers):RDF --> URI, for example, from which all other resources in the graph descend. The RDF processor continues from the root resource along its properties to other resources in the graph until it runs out of properties to traverse. RDF processing terminates at a <!--INDEX literals:RDF -->  literal, which is just what it sounds like: something that stands only for itself, generally represented by a string (e.g., "book," if there were no more information about the book in the graph). A literal resource contains only non-RDF data. A literal is a terminal point in the RDF graph.
   26: <P>For a resource to be labeled, it must be addressed through a universal resource identifier (URI). This address must be a unique string that designates what the resource is. In practice, most resources don't have identifiers because they are not nodes on the RDF graph that are meant to be accessed through a URI. <A HREF="#77004">Figure 10-2</A> is a modified version of <A HREF="#77002">Figure 10-1</A> that shows <I>Eric</I> as a resource identifier and <I>book</I> as a literal.
   27: <P><CENTER><IMG SRC="foo.gif"></CENTER>
   28: <P><I>Figure 10-2: <A NAME="77004"></A></I>
   29: <I>Resource to literal relationship</I>
   31: <P>Resources can have any number of properties, which themselves differ. In <A HREF="#77004">Figure 10-2</A>, <I>wrote</I> is a property of <I>Eric</I>. However, resources can also have multiple properties, as shown in <A HREF="#77006">Figure 10-3</A>.
   32: <P><CENTER><IMG SRC="foo.gif"></CENTER>
   33: <P><I>Figure 10-3: <A NAME="77006"></A></I>
   34: <I>RDF Graph with five nodes</I>
   36: <P>The RDF graph in <A HREF="#77006">Figure 10-3</A> has five nodes, two resources, and three literals. If this graph were represented in XML, it would probably have three different XML namespaces inside of it: RDF/XML, a <I>book</I> XML specification, and a <I>computer</I> XML specification. In English, the graph in <A HREF="#77006">Figure 10-3</A> might be expressed as follows:
   37: <BLOCKQUOTE>Eric wrote a book of unknown information. Eric's computer is 700 MHz and has an Athlon CPU.</BLOCKQUOTE>
   38: <P>Note that if Eric wrote a poem and a book, it would be possible to have two <I>wrote</I> properties for the same resource. Using the same property to point to separate resources is confusing, however. Instead, RDF containers (see the section <A HREF="#77069">"RDF containers</A>," later in this chapter) are the best way to organize data that would otherwise need a single property to branch in this way.
   39: <H4><A NAME="77064"></A> RDF URIs relating to namespaces</H4>
   40: <P>The  <!--INDEX RDF (Resource Description Framework):data model:URIs -->  <!--INDEX data model (RDF):URIs -->  <!--INDEX URIs (Universal 
   41: Resource Identifiers):RDF:namespaces -->  <!--INDEX namespaces:RDF, URIs and --> URIs used in RDF can be part of the element namespace. (See <A 
   42: HREF="ch02.html#77053">"The XUL Namespace" in Chapter 2</A> and in <A HREF="ch07.html#77031">"Namespaces and XBL" in Chapter 7</A> for more information about XML namespaces.) This use is especially true for properties. Some namespaces can be created from previous examples:
   43: <PRE>xmlns:rdf="<A HREF=""></A>#"
   44: xmlns:book="<A HREF=""></A>#"
   45: xmlns:comp=""</PRE>
   46: <P>When you use namespaces, the graph looks much different, as shown in <A HREF="#77008">Figure 10-4</A>.
   47: <P><CENTER><IMG SRC="foo.gif"></CENTER>
   48: <P><I>Figure 10-4: <A NAME="77008"></A></I>
   49: <I>Namespaces applied to Figure 10-3</I>
   52: <P>The resource identifier is often displayed in a URL format too, but it shouldn't use the same namespace URL as the RDF/XML file. The URL typically tries to describe a unique object, such as <I><A HREF=""></A></I>.<P></BLOCKQUOTE>
   53: <H4><A NAME="77065"></A> RDF triples: subject, predicate, and object</H4>
   54: <P>A triple  <!--INDEX statements, RDF, triples -->  <!--INDEX triples:RDF statements -->  <!--INDEX RDF (Resource Description Framework):statements, triples --> is a type of RDF statement. While an RDF statement can be a loose collection of resources, properties, and literals, a triple typically defines a tighter relationship between such elements.
   55: <P>The first part of a triple is the <I>subject</I>. This part is the resource described by the triple. The second part of the triple is the <I>predicate</I>. This part is a subject's property, a thing that joins it with something else. The third part is the <I>object</I>, which is either a resource or a literal.
   56: <P>RDF triples are significant because their stricter semantics guarantee the relationship between parts. A triple is a more formal version of the RDF statement, which is used more broadly. In <A HREF="#77008">Figure 10-4</A>, all statements are formally subject &gt; predicate &gt; object, so those statements are triples.
   57: <H4><A NAME="77066"></A> RDF data model terminology</H4>
   58: <P>When  <!--INDEX RDF (Resource Description Framework):data model:terminology -->  <!--INDEX data model (RDF):terminology --> reading RDF specifications, documentation, examples, and other related material on the Internet, you can encounter a dizzying array of terms that mean the same thing. <A HREF="#77020">Table 10-1</A> should help clarify these different terms. The italicized versions of the synonyms all do not technically mean the same thing, but are loose synonyms whose meanings depend on the context in which they are used.
   60: <P><I>Table 10-1: <A NAME="77020"></A></I>
   61: <I>Synonyms in RDF</I>
   62: <P><TABLE WIDTH=100% BORDER=1><TR><TD><B>  Common term</B></TD>	<TD><B>  Synonyms</B></TD></TR>
   63: <TR><TD>  Resource</TD>	<TD>  Subject, object</TD></TR>
   64: <TR><TD>  Resource identifier</TD>	<TD>  Name, (resource) URI, ID, identifier, URL, label</TD></TR>
   65: <TR><TD>  Properties</TD>	<TD>  Attributes</TD></TR>
   66: <TR><TD>  Statement</TD>	<TD>  Triple, tuple, binding, assertion</TD></TR>
   67: <TR><TD>  Subject</TD>	<TD>  Source, resource, node, root</TD></TR>
   68: <TR><TD>  Predicate</TD>	<TD>  Arc, (statement) URI, property, atom</TD></TR>
   69: <TR><TD>  Object</TD>	<TD>  Value, resource, node, literal</TD></TR></TABLE><P>
   71: <H3><A NAME="77067"></A> RDF Syntax</H3>
   72: <P>Mozilla <!--INDEX RDF (Resource Description Framework):syntax:overview -->  <!--INDEX syntax, RDF:overview -->  uses XML to represent RDF data. In 1999, the W3C defined the RDF/XML specification syntax to make it the most common way RDF is used. The RDF/XML format is sometimes called the RDF serialization syntax because it allows RDF models to be sent easily from one computer application to another in a common XML format.
   73: <P>When an application reads an RDF file, the Mozilla RDF processor builds a graphical interpretation in-memory. In this section, you learn how to build an RDF file from scratch and see what the graph looks like after running through Mozilla's RDF processor.
   75: <P><TT>RDF:RDF</TT> is a common namespace representation of RDF/XML data and is the one most frequently used in Mozilla files. However, it can be hard to read, so this chapter uses <TT>rdf:RDF</TT>. The W3C also used <TT>rdf:RDF</TT> in the RDF recommendation document.<P></BLOCKQUOTE>
   76: <H4><A NAME="77068"></A> Examining a simple RDF file</H4>
   77: <P>We begin <!--INDEX RDF (Resource Description Framework):syntax:files -->  <!--INDEX syntax, RDF:files -->  <!--INDEX files:RDF:syntax -->  with an example of an RDF file whose basic layout and simple syntax can be a model for the more advanced data introduced later. The RDF file shown in <A HREF="#77026">Example 10-1</A> is a list of three types of "flies," with the context of those "flies" inside a "jar." <A HREF="#77026">Example 10-1</A> also contains a namespace that defines these types of flies and shows the <TT>rdf</TT> and <TT>fly</TT> XML intertwined.
   79: <P><I>Example 10-1: <A NAME="77026"></A></I>
   80: <I>Simple RDF file with "fly" namespace</I>
   81: <PRE>   &lt;?xml version="1.0"?&gt;
   82:    &lt;rdf:RDF
   83:       xmlns:rdf="<A HREF=""></A>#"
   84:       xmlns:fly="<A HREF=""></A>#"&gt;
   85:      &lt;rdf:Description about="<A HREF=""></A>"&gt;
   86:        &lt;fly:types&gt;
   87:          &lt;rdf:Bag&gt;
   88:            &lt;rdf:li&gt;
   89:              &lt;rdf:Description fly:name="Horse"/&gt;
   90:            &lt;/rdf:li&gt;
   91:            &lt;rdf:li&gt;
   92:              &lt;rdf:Description fly:name="House"/&gt;
   93:            &lt;/rdf:li&gt;
   94:            &lt;rdf:li&gt;
   95:              &lt;rdf:Description fly:name="Fruit"/&gt;
   96:            &lt;/rdf:li&gt;
   97:          &lt;/rdf:Bag&gt;
   98:        &lt;/fly:types&gt;
   99:      &lt;/rdf:Description&gt;
  100:    &lt;/rdf:RDF&gt;</PRE>
  102: <P><TT> <!--INDEX rdf\:Description element --> &lt;rdf:Description&gt;</TT> is the tag used to outline a resource. <A HREF="#77026">Example 10-1</A> shows how the <TT>about</TT> attribute references the resource identifier and makes this resource unique in the document. Two resources cannot have the same <TT>about</TT> value in a document, just as tags cannot share an <TT>id</TT> in an XML document. Both attributes guarantee the unique nature of each element and relationship.
  103: <PRE>&lt;rdf:Description about="<A HREF=""></A>"&gt;
  104: &lt;fly:types&gt;
  105: &lt;rdf:Bag&gt;</PRE>
  106: <P><TT><A HREF=""></A></TT>, is the subject shown in the previous code snippet. <I>My jar of flies</I> is a resource definition and defines only what <I>flies</I> are inside of the statement. The predicate, which addresses a property in the resource, is defined by the tag <TT>&lt;types&gt;</TT> (of the <TT><A HREF=""></A>#</TT> namespace).
  107: <P>The final part of the statement, the object, is the actual data of the predicate and a container of type bag. The container is an RDF resource that "holds," or points to, a collection of other resources. In the next section, container types are discussed in depth. <A HREF="#77010">Figure 10-5</A> illustrates how the triple originates from the root subject and includes the container object.
  108: <P><CENTER><IMG SRC="foo.gif"></CENTER>
  109: <P><I>Figure 10-5: <A NAME="77010"></A></I>
  110: <I>The first statement of the graph, with labeled parts</I>
  112: <P>In this case, an RDF statement is extracted from the example, but no useful data is reached. Little can be done with an empty RDF container, and two more steps are needed to reach literals that contain names of the flies.
  113: <H4><A NAME="77069"></A> RDF containers</H4>
  114: <P>Containers  <!--INDEX RDF (Resource Description Framework):containers -->  <!--INDEX containers:RDF --> are a list of resources or literals. They are a form of RDF  <!--INDEX resources:RDF:containers --> resource. There are three different container types: <TT>bag</TT>, <TT>sequence</TT>, and <TT>alternative</TT>. <TT>Bag</TT> is an unordered list of items, whereas <TT>sequence</TT> is an ordered list of items. They both allow duplicate values. <TT>Alternative</TT> is a list of values that could replace a particular property in a resource. <TT>Sequence</TT> is the most popular container for use in Mozilla applications because it frequently uses ordered lists of data. A container's graphical definition is an entire separate statement about its type and the items it contains. In <A HREF="#77012">Figure 10-6</A>, you can see the type of the container defined in the RDF statement with the property <TT>rdf:type</TT>. The remaining properties are the container's items.
  115: <P><CENTER><IMG SRC="foo.gif"></CENTER>
  116: <P><I>Figure 10-6: <A NAME="77012"></A></I>
  117: <I>The second statement of the graph, with labeled parts</I>
  119: <P>Once the container is defined, you can examine its collection of elements. At this point in the RDF code, direct comparisons can again be made from the code to the graph:
  120: <PRE>&lt;rdf:Bag&gt;
  121: &lt;rdf:li&gt;
  122: &lt;rdf:Description ...</PRE>
  123: <P>Here, the <TT> <!--INDEX rdf\:li tag --> &lt;rdf:li&gt;</TT> tag is similar to the <TT>&lt;li&gt;</TT> tag in HTML, which stands for "list item." Moving from code to graph, the new representation is shown in <A HREF="#77012">Figure 10-6</A>.
  124: <P>In <A HREF="#77012">Figure 10-6</A>, the subject is the instance of the container. This statement does not begin from <TT>rdf:Bag</TT> because that resource is only a type definition. The actual items in the container originate from the instance created in memory by any RDF processor, including Mozilla's.
  126: <P>Mozilla's RDF processor fills in the <TT>rdf:*(1)</TT> of the resource identifier in <A HREF="#77012">Figure 10-6</A> with a hashed value. The same is true for the container's resource identifier. The actual values come out as something like <TT>rdf:#$0mhkm1</TT>, though the values change each time the RDF document is loaded.<P></BLOCKQUOTE>
  127: <P>Objects inside of the container have <!--INDEX properties:RDF:containers -->  properties identified automatically as <TT>rdf:_1</TT>, <TT>rdf:_2</TT>, etc., as defined by the RDF model specification. However, RDF applications such as Mozilla may use different identifiers to differentiate list objects.
  128: <H4><A NAME="77070"></A> Literals</H4>
  129: <P>The final  <!--INDEX RDF (Resource Description Framework):literals --> statement in <A HREF="#77026">Example 10-1</A> allows the predicate to reach the text data, the literal "horse" shown in <A HREF="#77014">Figure 10-7</A>. Note that the <TT>about</TT> reference on the <TT>Description</TT> is fictitious RDF, but it demonstrates the difference between a resource and a literal.
  130: <PRE>&lt;rdf:Description about="rdf:*(1)" fly:name="Horse"/&gt;</PRE>
  131: <P><CENTER><IMG SRC="foo.gif"></CENTER>
  132: <P><I>Figure 10-7: <A NAME="77014"></A></I>
  133: <I>The third statement of the graph, with labeled parts</I>
  135: <P>The previous RDF  <!--INDEX RDF (Resource Description Framework):syntax:shorthand -->  <!--INDEX syntax, RDF:shorthand --> code for the literal is syntactic shorthand. Using this type of shortcut can make RDF much easier to read. The previous code snippet is the same as the longer and more cumbersome one shown here:
  136: <PRE>&lt;rdf:Description about="rdf:*(1)"&gt;
  137: &lt;fly:name&gt;Horse&lt;/fly:name&gt;
  138: &lt;/rdf:Description&gt;</PRE>
  139: <P>The shorthand version of this statement can be useful when you have a lot of data or when you want to use one syntax to show all relationships in the graph.
  140: <H4><A NAME="77071"></A> The RDF syntax and RDF graphs</H4>
  141: <P><A HREF="#77016">Figure 10-8</A> shows the entire RDF graph for the RDF file in <A HREF="#77026">Example 10-1</A>. This graph was compiled by combining the concepts you've seen in Figures 10-5 through 10-7.
  142: <P>As you can see, the statements fit together quite nicely. Four resources originate from the container, and one is the container type definition. The other two properties are numbered according to their order in the RDF file.
  143: <P><CENTER><IMG SRC="foo.gif"></CENTER>
  144: <P><I>Figure 10-8: <A NAME="77016"></A></I>
  145: <I>The full graph</I>
  147: <H3><A NAME="77072"></A> Building an RDF File from Scratch</H3>
  148: <P>Now that  <!--INDEX RDF (Resource Description Framework):files:creating -->  <!--INDEX files:RDF:creating --> you understand the basic principles of a simple RDF file, this section steps through the creation of an RDF file from information found in regular text:
  149: <BLOCKQUOTE>There is a jar with the name urn:root. Inside of it there are two types of flies listed as House and Horse.
  150: There are three Horse flies. The Face Fly, coded in green, is officially identified as "musca autumnalis". The Stable Fly, coded in black, has the identification "stomoxys_calcitrans." The red-coded Horn Fly, located in Kansas, is identified as "haematobia_irritans."
  151: There are also three house flies. "musca_domestica," coded in brown, has the name "Common House Fly." A gray fly named "Carrion Fly" has the ID "sarcophagid" and is found globally. Finally, The "Office Fly," coded with white, is prevalent in the Bay Area.</BLOCKQUOTE>
  152: <P>You can use the techniques described here to model the data you want in your application: spreadsheet-like rosters of people, family trees, or catalogs of books or other items.
  153: <H4><A NAME="77073"></A> Identify namespaces</H4>
  154: <P>The new  <!--INDEX namespaces:identifying, creating RDF files -->  <!--INDEX RDF (Resource Description Framework):files:identifying namespaces -->  <!--INDEX files:RDF:identifying namespaces --> RDF file will have three namespaces including the RDF namespace. The result is two different data types that are connected in an RDF graph. For the sake of the example, one namespace is not in the standard URL format. Here is how the RDF file namespaces are set up:
  155: <PRE>&lt;?xml version="1.0"?&gt;
  156: &lt;rdf:RDF xmlns:rdf="<A HREF=""></A>#"
  157: xmlns:fly="<A HREF=""></A>#"
  158: xmlns:location="fly-location#"&gt;
  159: &lt;/rdf:RDF&gt;</PRE>
  160: <H4><A NAME="77074"></A> Root resource</H4>
  161: <P>This file's  <!--INDEX resources:RDF:creating files -->  <!--INDEX root resources, RDF files -->  <!--INDEX RDF (Resource Description Framework):files:root resources -->  <!--INDEX files:RDF:root resources --> root resource is an <TT>urn:root</TT>, which is the conventional name for root nodes in Mozilla's RDF files. When rendering RDF files, defining a root node for processing the document can be useful-especially when building templates. This root node can be entered as the first item in the file:
  162: <PRE>&lt;?xml version="1.0"?&gt;
  163: &lt;rdf:RDF xmlns:rdf="<A HREF=""></A>#"
  164: xmlns:fly="<A HREF=""></A>#"
  165: xmlns:location="fly-location#"&gt;
  166: &lt;rdf:Description about="urn:root"&gt;
  167: &lt;/rdf:Description&gt;
  168: &lt;/rdf:RDF&gt;</PRE>
  169: <H4><A NAME="77075"></A> Root sequence</H4>
  170: <P>Next, a  <!--INDEX sequences, RDF:creating files -->  <!--INDEX root sequences, RDF files -->  <!--INDEX RDF (Resource Description Framework):files:root sequesces -->  <!--INDEX files:RDF:root sequesces --> generic tag needs to be used to specify a sequence of "fly" data. As in <A HREF="#77028">Example 10-2</A>, <TT>&lt;fly:list&gt;</TT> is used as a list of fly types. This tag is a generic name because of the way XUL templates process lists of RDF data. If a list of data has sublists, as in the following examples, then they must use the same tag name to recurse correctly for the data they contain.
  171: <P><A HREF="#77028">Example 10-2</A> represents all the information given in the first paragraph of the text example: "There is a jar set up with the name <I>urn:root</I>. Inside of it there are two types of flies, listed as House and Horse."
  173: <P><I>Example 10-2: <A NAME="77028"></A></I>
  174: <I>RDF root sequence</I>
  175: <PRE> &lt;?xml version="1.0"?&gt;
  176:  &lt;rdf:RDF xmlns:rdf="<A HREF=""></A>#"
  177:           xmlns:fly="<A HREF=""></A>#"
  178:           xmlns:location="fly-location#"&gt;
  179:    &lt;rdf:Description about="urn:root"&gt;
  180:      &lt;fly:list&gt;
  181:        &lt;rdf:Seq&gt;
  182:          &lt;rdf:li&gt;
  183:            &lt;rdf:Description ID="House" fly:label="House"/&gt;
  184:          &lt;/rdf:li&gt;
  185:          &lt;rdf:li&gt;
  186:            &lt;rdf:Description ID="Horse" fly:label="Horse"/&gt;
  187:          &lt;/rdf:li&gt;
  188:        &lt;/rdf:Seq&gt;
  189:      &lt;/fly:list&gt;
  190:    &lt;/rdf:Description&gt;
  191:  &lt;/rdf:RDF&gt;</PRE>
  193: <P>An RDF sequence resides with its list of resources inside <TT>&lt;fly:list&gt;</TT>. Here, shorthand RDF specifies a label with the <TT>fly:label</TT> attribute. The <TT>ID</TT> attribute within this sequence is actually a pointer to the main definition of the resource described by an <TT>about</TT> attribute of the same value. The <TT>about</TT> attribute includes a <TT>#</TT> in its identifier, much like HTML anchors use <TT>&lt;a href="#frag"&gt;</TT> to refer to <TT>&lt;a name="frag"&gt;</TT>. For example, <TT>ID="Horse"</TT> points to <TT>about="#Horse</TT>" elsewhere in the file, allowing you to add to the description of any element with new properties and resources.
  194: <H4><A NAME="77076"></A> Secondary sequences and literals</H4>
  195: <P>The  <!--INDEX sequences, RDF:creating files -->  <!--INDEX secondary sequences, RDF files -->  <!--INDEX RDF (Resource Description Framework):files:secondary sequesces -->  <!--INDEX files:RDF:secondary sequesces --> <TT>Horse</TT> and <TT>House</TT> resources need to be defined next. <A HREF="#77030">Example 10-3</A> shows the creation of <TT>Horse</TT> from the second paragraph. The process for creating <TT>House</TT> is almost identical.
  197: <P><I>Example 10-3: <A NAME="77030"></A></I>
  198: <I>The Horse sequence</I>
  199: <PRE> &lt;rdf:Description about="#Horse"&gt;
  200:      &lt;fly:list&gt;
  201:        &lt;rdf:Seq&gt;
  202:          &lt;rdf:li&gt;
  203:            &lt;rdf:Description about="musca_autumnalis"
  204:                             fly:label="Face fly"
  205:                             fly:color="green"/&gt;
  206:          &lt;/rdf:li&gt;
  207:          &lt;rdf:li&gt;
  208:            &lt;rdf:Description about="stomoxys_calcitrans"
  209:                             fly:label="Stable Fly"
  210:                             fly:color="black"/&gt;
  211:          &lt;/rdf:li&gt;
  212:          &lt;rdf:li&gt;
  213:            &lt;rdf:Description about="haematobia_irritans"
  214:                             fly:label="Horn Fly"
  215:                             fly:color="red"
  216:                             location:location="Kansas"/&gt;
  217:          &lt;/rdf:li&gt;
  218:        &lt;/rdf:Seq&gt;
  219:      &lt;/fly:list&gt;
  220:    &lt;/rdf:Description&gt;</PRE>
  222: <P>Here the shorthand RDF definition continues to use only the attributes. Again, a <TT>&lt;fly:list&gt;</TT> is defined and the items inside it are listed. The listed values have multiple attribute values, all of which are RDF literals. In longhand with RDF showing all literals, the last item would be written out as follows:
  223: <PRE>&lt;rdf:li&gt;
  224: &lt;rdf:Description about="haematobia_irritans "&gt;
  225: &lt;fly:label&gt;Horn Fly&lt;/fly:label&gt;
  226: &lt;fly:color&gt;red&lt;/fly:color&gt;
  227: &lt;location:location&gt;Kansas&lt;/location:location&gt;
  228: &lt;/rdf:Description&gt;
  229: &lt;/rdf:li&gt;</PRE>
  230: <P>The two different namespace literals are both resource attributes. <TT>haematobia_irritans</TT> is used as the resource identifier because it is a unique value among all data.
  231: <P>Laying out the data in the same pattern gives you the final, full RDF file in <A HREF="#77032">Example 10-4</A>.
  233: <P><I>Example 10-4: <A NAME="77032"></A></I>
  234: <I>Entire RDF file</I>
  235: <PRE> &lt;?xml version="1.0"?&gt;
  236:  &lt;rdf:RDF xmlns:rdf="<A HREF=""></A>#"
  237:           xmlns:fly="<A HREF=""></A>#"
  238:           xmlns:location="fly-location#"&gt;
  239:    &lt;rdf:Description about="urn:root"&gt;
  240:      &lt;fly:list&gt;
  241:        &lt;rdf:Seq&gt;
  242:          &lt;rdf:li&gt;
  243:            &lt;rdf:Description ID="House" fly:label="House"/&gt;
  244:          &lt;/rdf:li&gt;
  245:          &lt;rdf:li&gt;
  246:            &lt;rdf:Description ID="Horse" fly:label="Horse"/&gt;
  247:          &lt;/rdf:li&gt;
  248:        &lt;/rdf:Seq&gt;
  249:      &lt;/fly:list&gt;
  250:    &lt;/rdf:Description&gt;
  251:    &lt;rdf:Description about="#Horse"&gt;
  252:      &lt;fly:list&gt;
  253:        &lt;rdf:Seq&gt;
  254:          &lt;rdf:li&gt;
  255:            &lt;rdf:Description about="musca_autumnalis"
  256:                             fly:label="Face fly"
  257:                             fly:color="green"/&gt;
  258:          &lt;/rdf:li&gt;
  259:          &lt;rdf:li&gt;
  260:            &lt;rdf:Description about="stomoxys_calcitrans"
  261:                             fly:label="Stable Fly"
  262:                             fly:color="black"/&gt;
  263:          &lt;/rdf:li&gt;
  264:          &lt;rdf:li&gt;
  265:            &lt;rdf:Description about="haematobia_irritans"
  266:                             fly:label="Horn Fly"
  267:                             fly:color="red"
  268:                             location:location="Kansas"/&gt;
  269:          &lt;/rdf:li&gt;
  270:        &lt;/rdf:Seq&gt;
  271:      &lt;/fly:list&gt;
  272:    &lt;/rdf:Description&gt;
  273:    &lt;rdf:Description about="#House"&gt;
  274:      &lt;fly:list&gt;
  275:        &lt;rdf:Seq&gt;
  276:          &lt;rdf:li&gt;
  277:            &lt;rdf:Description about="musca_domestica"
  278:                             fly:label="Common House Fly"
  279:                             fly:color="brown"/&gt;
  280:          &lt;/rdf:li&gt;
  281:          &lt;rdf:li&gt;
  282:            &lt;rdf:Description about="sarcophagid"
  283:                             fly:label="Carrion Fly"
  284:                             fly:color="gray"
  285:                             location:location="Worldwide"/&gt;
  286:          &lt;/rdf:li&gt;
  287:          &lt;rdf:li&gt;
  288:            &lt;rdf:Description about="musca_oficio"
  289:                             fly:label="Office Fly"
  290:                             fly:color="white"
  291:                             location:location="California, Bay Area"/&gt;
  292:          &lt;/rdf:li&gt;
  293:        &lt;/rdf:Seq&gt;
  294:      &lt;/fly:list&gt;
  295:    &lt;/rdf:Description&gt;
  296:  &lt;/rdf:RDF&gt;</PRE>
  298: <P><A HREF="#77032">Example 10-4</A> shows the RDF data used in several template examples in <A HREF="ch09.html#77034">Chapter 9</A>. <A 
  299: HREF="ch09.html#77022">Example 9-4</A> includes the <I>10-4.rdf</I> datasource, as do many of those templates. You can copy the data out of <A 
  300: HREF="#77032">Example 10-4</A> and into a file of the same name to use as a datasource.
  301: <H2><A NAME="77077"></A> The Mozilla Content Model</H2>
  302: <P>One theme  <!--INDEX content model:overview -->  <!--INDEX Gecko rendering engine:Mozilla content model --> of this book-and a general goal of the Mozilla development environment-is that developers can create real applications using many of the same technologies they use to create a web page. The Gecko rendering engine, sitting at the heart of Mozilla and happily rendering web content, XML files, XUL interfaces, and whatever else they can support, is what makes this type of development possible. But how does Gecko know what to render and how? How can RDF data be handed over so that Gecko knows how to draw it?
  303: <P>When a browser uses the same engine to draw everything-its own interface as well as the various kinds of content it supports-that engine treats everything as content. Gecko needs a way to understand all the various parts of the Mozilla browser itself-such as the sidebar, the toolbars, and the mail folders and mail messages-as resources it can render and display in the Mozilla chrome. This approach to the Mozilla application interface is called the content model.
  304: <P>In Mozilla's content model, XUL documents and other interface resources are transformed into RDF when they are read. Each chunk of content is represented as a separate RDF datasource (see the next section, <A HREF="#77078">"Datasources</A>," for more information) and is then fed to the XUL Content Builder and rendered as the actual bits on the screen, as <A HREF="#77018">Figure 10-9</A> shows.
  305: <P><CENTER><IMG SRC="foo.gif"></CENTER>
  306: <P><I>Figure 10-9: <A NAME="77018"></A></I>
  307: <I>Diagram of Mozilla's content model</I>
  309: <P>As you can see in <A HREF="#77018">Figure 10-9</A>, the content model can be complex. The XUL documents in <A HREF="#77018">Figure 10-9</A> are files such as <I>navigator.xul</I>, which defines the main browser window's basic layout; the RDF documents include files like <I>help-toc.rdf</I>, which defines the Mozilla Help viewer's table of contents. The list of mail folders and accounts shown in <A HREF="#77034">Example 10-5</A> are part of the built-in data that Mozilla renders into browser content.
  310: <P>Whatever the source, the content model gets everything processed in-memory as RDF so that any data can be combined and formatted into XUL or other interface code. All sources of RDF data are called datasources.
  311: <H3><A NAME="77078"></A> Datasources</H3>
  312: <P>A datasource  <!--INDEX content model:datasources -->  <!--INDEX datasources:content model --> is a collection of related, typically homogenous, RDF statements. A datasource may be a single RDF file like <I>localstore.rdf</I>, a combination of files, or RDF structures that exist only in memory (as discussed later).
  313: <P>In Mozilla, datasources represent the messages in your email inbox, your bookmarks, the packages you installed, your browser history, and other sets of data. Datasources can be combined easily (or "composed," which is where the term "composite datasource" comes from).
  314: <H4><A NAME="77079"></A> A datasource example: mailboxes</H4>
  315: <P>Several  <!--INDEX content model:datasources:example -->  <!--INDEX datasources:content model:example --> datasources describe all the folders and messages in Mozilla's email. A root datasource called <TT>msgaccounts</TT> describes which mail servers and accounts are present. Separate datasources then represent each account separately. These datasources are composed to create the entire email storage system. The higher levels of this content structure look like <A HREF="#77034">Example 10-5</A>.
  317: <P><I>Example 10-5: <A NAME="77034"></A></I>
  318: <I>Content model of email datasources</I>
  319: <PRE> msgaccounts:/
  320:  +-- <A HREF=""></A>#child</TD> --&gt;
  321:      imap:</TD><TT><I>//<A HREF=""></A></I></TT>
  322:      |    +-- <A HREF=""></A>#IsServer</TD> --&gt; "true"
  323:      |    +-- <A HREF=""></A>#child</TD> --&gt;
  324:      |        imap:</TD><TT><I>//<A HREF=""></A></I></TT>
  325:      |    +-- <A HREF=""></A>#TotalMessages</TD> --&gt; "4"
  326:      |    +-- <A HREF=""></A>#IsServer</TD> --&gt; "false"
  327:      |    +-- <A HREF=""></A>#MessageChild</TD> --&gt;
  328:      |        imap_message://<A HREF=""></A>#1
  329:      |    +-- <A HREF=""></A>#MessageChild</TD> --&gt;
  330:      |        imap_message://<A HREF=""></A>#2
  331:      |    +-- <A HREF=""></A>#MessageChild</TD> --&gt;
  332:      |    etc...
  333:      |
  334:  +-- <A HREF=""></A>#child</TD> --&gt;
  335:      mailbox:</TD><TT><I>//<A HREF=""></A></I></TT>
  336:      |    +-- <A HREF=""></A>#IsServer</TD> --&gt; "true"
  337:      |    +-- <A HREF=""></A>#child</TD> --&gt;
  338:      |        mailbox:</TD><TT><I>//<A HREF=""></A></I></TT>
  339:      |    +-- <A HREF=""></A>#TotalMessages</TD> --&gt; "2"
  340:      |    etc...</PRE>
  342: <P>Each direct child of the root <I>msgaccounts:/</I> is a mail server. This portion of the graph shows two Mozilla email accounts that are the primary children: <I>imap://<A HREF=""></A></I> and <I>mailbox://<A HREF=""></A></I>. These two accounts are entirely different datasources that can exist on their own. The content model for email actually extends much lower than what is represented in this outline. It uses RDF to represent the data all the way into the actual message lists.
  343: <H4><A NAME="77080"></A> Types of datasources</H4>
  344: <P>As you  <!--INDEX content model:datasources:types -->  <!--INDEX datasources:content model:types --> may have already inferred, email accounts are not actually RDF files. Mozilla provides a custom RDF map of all email accounts and messages and the content model represents the accounts and their relationships to one another as RDF so they can be integrated and rendered properly. The interface to this custom mail RDF map makes it possible to display a list of messages and mailboxes in a <TT>&lt;tree&gt;</TT> template.
  345: <P>Another example of a datasource, the <I>in-memory-datasource,</I> doesn't come from an actual RDF file. When an in-memory datasource is created, it doesn't contain data. However, data can be inserted into it and stored in memory until the datasource is destroyed. In-memory datasources frequently represent ephemeral data like search results. Other basic datasource types are described in <A HREF="#77022">Table 10-2</A>.
  347: <P><I>Table 10-2: <A NAME="77022"></A></I>
  348: <I>Types of datasources</I>
  349: <P><TABLE WIDTH=100% BORDER=1><TR><TD><B>  Type</B></TD>	<TD><B>  Description</B></TD></TR>
  350: <TR><TD>  Local datasource</TD>	<TD>  A local datasource is an RDF graph contained in an RDF/XML file on a local disk. All RDF files in the chrome registry (e.g., </TD><I>all-packages.rdf</I> in the <I>chrome</I> directory, which keeps track packages installed in Mozilla) are local datasources.</TR>
  351: <TR><TD>  Remote datasource</TD>	<TD>  RDF can be accessed locally or remotely. A remote datasource is an RDF/XML file stored on a server and accessed with a URL.</TD></TR>
  352: <TR><TD>  In-memory datasource</TD>	<TD>  An in-memory datasource exists only in memory during a Mozilla session. In-memory datasources are built with </TD><I>assertions</I>, statements that build an in-memory data model by adding resources, properties, and value to those.</TR>
  353: <TR><TD>  Built-in datasource</TD>	<TD>  These unique, prefabricated datasources represent something used often in Mozilla, such as a built-in </TD><I>filesystem</I> datasource and a <I>history</I> datasource.</TR>
  354: <TR><TD>  Composite datasource</TD>	<TD>  A composite datasource may be a combination of any of the datasources previously listed. RDF allows you to merge different graphs.</TD></TR></TABLE><P>
  356: <H2><A NAME="77081"></A> RDF Components and Interfaces</H2>
  357: <P>Once you are comfortable using XUL templates to display RDF data (see <A HREF="ch09.html#77034">Chapter 9</A>), you should explore the various 
  358: ways to create and change that data. In Mozilla, data is generally RDF, since all data in Mozilla is either represented formally in RDF or passed through the RDF-based content model for display. Use the tools described in this section to manipulate RDF and the data it represents.
  359: <P>Mozilla has a great set of interfaces for creating, manipulating, and managing RDF, and it also provides ready-made RDF components that represent datasources used in Mozilla. Think of RDF interfaces as ways to manipulate RDF directly and of RDF components as sets of the interfaces already associated with a particular kind of data, such as bookmarks. Interfaces tend to deal with the RDF model itself, without regard to the kinds of data being handled, while RDF components give you control over specific Mozilla data. See the next two sections for more information on RDF interfaces and components.
  360: <H3><A NAME="77082"></A> What Is an RDF Component?</H3>
  361: <P>An RDF  <!--INDEX RDF (Resource Description Framework):components, overview -->  <!--INDEX components:RDF, overview --> component may implement any number of the general RDF interfaces described here, in addition to special interfaces for accessing and controlling the data the datasource represents. For example, <TT>;1?name=internetsearch</TT> is an RDF component used to control Mozilla's internet searching facility. In Mozilla, a component can act as a library of code specific to a given set of data or domain. The <TT> <!--INDEX internetsearch component --> internetsearch</TT> component is instantiated and used to recall text entered in a previous search:
  362: <PRE>var searchDS = Components.classes[";1?name=internetsearch"]
  363: .getService(Components.interfaces.nsIInternetSearchService);
  365: searchDS.RememberLastSearchText(escapedSearchStr);</PRE>
  366: <P>This RDF component implements an interface called <I> <!--INDEX nsIInternetSearchService interface -->  <!--INDEX interfaces:nsIInternetSearchService --> nsIInternetSearchService</I>, which is selected from the component and used to call the <TT>RememberLastSearchText</TT> method. Although you can also use the <TT>getService</TT> method to get one of a component's RDF interfaces (e.g., by using <TT>getService(Components.interfaces.nsIRDFDataSource)</TT>), doing so is seldom necessary in practice. RDF components are tailored to the datasources they represent and usually provide all the access you need to access that data directly. <A HREF="#77036">Example 10-6</A> lists RDF components in Mozilla.
  368: <P><I>Example 10-6: <A NAME="77036"></A></I>
  369: <I>RDF-specific components built into Mozilla</I>
  370: <PRE>;1
  408: <P>From this list, components used often in the Mozilla source code include bookmarks, history, mail and news folders, and address books.
  409: <BLOCKQUOTE><HR><B>Special URIs</B>
  410: <P>Mozilla's built-in datasource  <!--INDEX URIs (Universal Resource Identifiers):datasource components -->  <!--INDEX components:URIs --> components have special URIs for access. Here is the format used to determine the URI from the component reference:
  411: <P>Component:
  412: <PRE>;1?name=SomeName</PRE>
  413: Datasource URI:
  414: <PRE>rdf:SomeName</PRE>
  415: The URI is also accessible as a datasource property:<HR></BLOCKQUOTE>
  416: foo-ds.URI
  418: <H3><A NAME="77083"></A> What Are RDF Interfaces?</H3>
  419: <P>RDF interfaces  <!--INDEX RDF (Resource Description Framework):interfaces:overview -->  <!--INDEX interfaces:RDF:overview --> are interfaces in Mozilla designed to manipulate RDF structures and data. They typically deal with RDF generally, rather than specific sets of data (as in the case of components). A common use for an RDF interface in JavaScript, shown in <A HREF="#77038">Example 10-7</A>, is to use <I>nsIRDFService</I> to retrieve or assert the root node of an RDF datasource.
  421: <P><I>Example 10-7: <A NAME="77038"></A></I>
  422: <I>Creating a root node</I>
  423: <PRE> // get the nsIRDFService interface and assign it to RDF
  424:  RDF = Components.classes</TD><A HREF="MAILTO:[`;1">[`;1</A>'].
  425:        getService(Components.interfaces.nsIRDFService);
  426:  // call the GetResource method from the interface
  427:  rootResource = RDF.GetResource('urn:root');</PRE>
  429: <P>Like all Mozilla interfaces, RDF interfaces (shown in <A HREF="#77024">Table 10-3</A>) are defined in IDL and can be accessed through XPCOM. The examples in this section use JavaScript and XPConnect to access the components for simplicity, but you can also use these interfaces with C++, as they are often in the actual Mozilla source code. Most interfaces deal with datasources, which drive the use of RDF in Mozilla.
  431: <P><I>Table 10-3: <A NAME="77024"></A></I>
  432: <I>Mozilla's built-in RDF interfaces</I>
  433: <P><TABLE WIDTH=100% BORDER=1><TR><TD><B>  RDF interface</B></TD>	<TD><B>  Description</B></TD></TR>
  434: <TR><TD>  nsIRDFService</TD>	<TD>  Mostly used for retrieving, datasources, resources, and literals. It also registers and unregisters datasources and resources.</TD></TR>
  435: <TR><TD>  nsIRDFCompositeDataSource</TD>	<TD>  Allows the addition and removal of a datasource from a composite datasource (which may be empty).</TD></TR>
  436: <TR><TD>  nsIRDFDataSource, nsIRDFPurgeableDataSource, nsIRDFRemoteDataSource</TD>	<TD>  Mostly used for adding, removing, and changing triples in a datasource. It provides the means to change the graph.</TD></TR>
  437: <TR><TD>  nsIRDFNode, nsIRDFResource, nsIRDFLiteral</TD>	<TD>  Provide an equality function. Values for resources and literals can be retrieved. Objects of these types are retrieved from </TD><TT>nsIRDFService</TT>.</TR>
  438: <TR><TD>  nsIRDFContainer</TD>	<TD>  Provides vector-like access to an RDF container's elements.</TD></TR>
  439: <TR><TD>  nsIRDFContainerUtils</TD>	<TD>  Provides container creation and other container-related functions.</TD></TR>
  440: <TR><TD>  nsIRDFObserver</TD>	<TD>  Fires events when data is changed in a datasource.</TD></TR>
  441: <TR><TD>  nsIRDFXMLParser, nsIRDFXMLSerializer, nsIRDFXMLSink, nsIRDFXMLSource</TD>	<TD>  Used for working with RDF/XML. Functions are provided for parsing files and serializing content.</TD></TR></TABLE><P>
  443: <P>The sheer variety of RDF interfaces may seem overwhelming, but all interfaces serve different purposes and are often used in conjunction with one another. In your particular application space, you may find yourself using some subsets of these interfaces constantly and others not at all. This section describes some of the most commonly used functions. You can look up all of interfaces in their entirety <!--INDEX web sites:RDF interfaces -->  at <I><A HREF=""></A></I>.
  444: <H3><A NAME="77084"></A> nsIRDFService</H3>
  445: <P>If you <!--INDEX nsIRDFService interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFService -->  <!--INDEX interfaces:RDF:nsIRDFService -->  will do any sort of RDF processing, you need to use the <I>nsIRDFService</I> interface. It provides the basics for working with datasources, resources, and literals, and is useful when you process RDF data. <I>nsIRDFService</I> can be initialized by using the <TT>getService</TT> method of the <TT>rdf-service</TT> class:
  446: <PRE>RDF = Components.<A HREF="MAILTO:classes[`;1">classes[`;1</A>']
  447: getService(Components.interfaces.nsIRDFService);</PRE>
  448: <P>Once the service is available, it's ready to go to work. Even though no datasource is created yet (in this particular example), the RDF service can still get resources and literals, as shown in the next section.
  449: <H4><A NAME="77085"></A> Getting a resource</H4>
  450: <P>Once a resource <!--INDEX resources:nsIRDFService interface -->  is created (e.g., with the identifier <TT>urn:root</TT> in <A HREF="#77038">Example 10-7</A>), it needs to be added to a datasource:
  451: <PRE>rootResource = RDF.GetResource('urn:root');</PRE>
  452: <P>When a resource is already registered under the given identifier (see <A HREF="#77088">"Registering and unregistering datasources</A>," later in this chapter for more information about RDF registration), then <TT> <!--INDEX GetResource function --> GetResource</TT> returns that resource.
  453: <H4><A NAME="77086"></A> Getting an anonymous resource</H4>
  454: <P>Anonymous resources are resources with no resource identifier. Here is the creation of a new anonymous resource and a test of its anonymity:
  455: <PRE>anonResource = RDF.GetAnonymousResource( );
  456: // This would be true. Checking is not necessary, just here for example.
  457: isAnon = RDF.isAnonymousResource(anonResource);</PRE>
  458: <P>Typically, these resources are turned into containers, as shown in the next section. Anonymous resources exist when names are not needed and a simple reference to that resource is all that is required.
  459: <H4><A NAME="77087"></A> Getting a literal</H4>
  460: <P>The <TT> <!--INDEX GetLiteral function --> GetLiteral</TT> function  <!--INDEX literals:nsIRDFService interface --> returns the given name in the format of a literal, which you can then use to assert into an RDF graph as a resource.
  461: <PRE>myName = RDF.GetLiteral('Eric');</PRE>
  462: <P>Variations on this function are <TT>GetIntLiteral</TT> and <TT>GetDateLiteral</TT>.
  463: <H4><A NAME="77088"></A> Registering and unregistering datasources</H4>
  464: <P>If you create  <!--INDEX datasources:registering -->  <!--INDEX registering:datasources -->  <!--INDEX RDF (Resource Description 
  465: Framework):datasources, registering --> a Mozilla application that uses the same datasource or RDF resources in different ways, you may want to register the datasource with Mozilla. When you register a datasource, you register it as a component in Mozilla (see <A HREF="ch08.html#77062">"Component Manager" in Chapter 8</A> for more information on Mozilla's component model), which means it can be accessed and used as easily as any other XPCOM component, and from anywhere in Mozilla.
  466: <P>To register a datasource, call the <TT> <!--INDEX RegisterDatasource method --> RegisterDatasource</TT> method of the RDF Service. In this example, the datasource already exists and is assigned to a variable named <I>myDatasource</I>:
  467: <PRE>RDF.RegisterDataSource(myDatasource, false);</PRE>
  468: <P>In this case, <I>myDatasource</I> is the datasource name, and the <TT>false</TT> parameter specifies that this datasource is not replacing a datasource with the same name. Once a datasource is registered with the component manager in this way, it can be retrieved by name and associated with another instance:
  469: <PRE>secondDatasource = anotherRDF.GetDataSource("My Datasource");</PRE>
  470: <P>To unregister a datasource from the RDF Service, pass the datasource into the <TT>UnRegisterDataSource</TT> function:
  471: <PRE>RDF.UnRegisterDataSource(myDatasource);</PRE>
  472: <P>Once it's unregistered, a datasource is no longer available to other instances of the RDF Service. Registered resources work the same way as datasources in the RDF Service: if a resource is registered with the RDF Service, then it is available in every instance of RDF Service. To get two different instances of the same registered datasource and unregister its use:
  473: <PRE>newResource = RDF.GetResource('my.resource');
  474: RDF.RegisterResource(newResource,false);
  475: notNewResource = RDF.GetResource('my.resource');
  476: RDF.UnRegisterResource(notNewResource);</PRE>
  478: <P>If you register resources and datasources, be sure to use the <I>overwrite</I> Boolean variable on <TT>RegisterDataSource</TT> and <TT>RegisterResource</TT> to avoid overwriting existing datasources.<P></BLOCKQUOTE>
  479: <H4><A NAME="77089"></A> Getting a remote datasource</H4>
  480: <P>Finally, <I>nsIRDFService</I> provides <!--INDEX datasources:remote, getting -->  <!--INDEX remote datasources, getting -->  a useful method that loads a datasource from a remote server, which is a process that occurs asynchronously. Compared to forthcoming discussions about datasource loading, <TT>GetDataSource</TT> is a real shortcut:
  481: <PRE>remoteDatasource = RDF.GetDataSource('<A HREF=""></A>');</PRE>
  483: <P>Remember that RDF files requested in this way must be set with the text/rdf MIME type on the web server to load properly.<P></BLOCKQUOTE>
  484: <H3><A NAME="77090"></A> nsIRDFCompositeDataSource</H3>
  485: <P>When you work  <!--INDEX nsIRDFCompositeDataSource interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFCompositeDataSource -->  <!--INDEX interfaces:RDF:nsIRDFCompositeDataSource --> with multiple datasources, you can make things easier by grouping them, which <I>nsIRDFCompositeDataSource</I> allows you to do. This functionality aggregates data in a number of Mozilla's applications. To get this interface, invoke:
  486: <PRE>composite_datasource
  487: = ';1?name=composite-datasource';
  488: compDataSource = Components.classes[composite_datasource]
  489: getService(Components.interfaces.nsIRDFCompositeDataSource);</PRE>
  490: <P>Once you have the interface, adding and removing datasources from the composite is easy. You can also enumerate the datasources by using the <TT>getNext</TT> method. <A HREF="#77040">Example 10-8</A> demonstrates how to add, remove, and cycle through datasources.
  492: <P><I>Example 10-8: <A NAME="77040"></A></I>
  493: <I>Manipulating datasources</I>
  494: <PRE> compDataSource.AddDataSource(datasource1);
  495:  compDataSource.AddDataSource(datasource2);
  496:  compDataSource.AddDataSource(datasource3);
  497:  compDataSource.RemoveDataSource(datasource1);
  498:  allDataSources = compDataSource.GetDataSources( );
  499:  datasource2 = allDataSources.getNext( );
  500:  datasource2.QueryInterface(Components.interfaces.nsIRDFDataSource);
  501:  datasource3 = allDataSources.getNext( );
  502:  datasource3.QueryInterface(Components.interfaces.nsIRDFDataSource);</PRE>
  504: <P>In <A HREF="#77040">Example 10-8</A>, <TT>allDataSources</TT> is an <I>nsISimpleEnumerator</I> returned by the <TT>GetDataSources</TT> method on the composite datasource. <TT>datasource1</TT> is removed from the composite, and then the remaining datasources are cycled through. This step provides a way to iterate through a collection of datasources. <I>nsIRDFCompositeDatasource</I> also inherits the many functions of <I>nsIRDFDataSource</I>; refer to the section <A HREF="#77091">"nsIRDFDataSource</A>" for more information.
  505: <H3><A NAME="77091"></A> nsIRDFDataSource</H3>
  506: <P>The <I> <!--INDEX nsIRDFDataSource interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFDataSource -->  <!--INDEX interfaces:RDF:nsIRDFDataSource --> nsIRDFDataSource</I> interface is large, with twenty functions and one attribute (<TT>URI</TT>), so it's one of the most common interfaces used to manipulate RDF data. <I>nsIRDFDataSource</I> contains all the components in <A HREF="#77036">Example 10-6</A> with "datasource" in their contract IDs, along with other common components:
  507: <PRE>;1
  512: <P>The <I>nsIRDFDataSource</I> interface is meant to handle some of the core interaction with the datasource. APIs such as <TT>URI</TT>, <TT>GetTarget</TT>, <TT>Assert</TT>, and <TT>Change</TT> are helpful for working on the RDF graph itself. For example, the <TT>;1?name=in-memory-datasource</TT> RDF component demonstrates the use of the <I>nsIRDFDataSource</I> interface. When this component is created, it's a blank datasource in memory, into which objects are inserted, changed, and removed. You can access the <I>nsIRDFDataSource</I> interface from the RDF component by first constructing an RDF graph in the in-memory datasource:
  513: <PRE>mem = ';1?name=in-memory-datasource';
  514: datasource = Components.classes[mem].
  515: createInstance(Components.interfaces.nsIRDFDataSource);</PRE>
  516: <P>Of the twenty functions (found at <I><A HREF=""></A></I>) in this interface, we show only a handful here:
  517: <UL><P><LI>Assertion and removal<P>
  518: <P><LI>Changing values<P>
  519: <P><LI>Moving triples<P>
  520: <P><LI>HasAssertion<P>
  521: <P><LI>GetTarget<P>
  522: <P><LI>GetSource<P></UL>
  523: <P>The main purpose of the <I>nsIRDFDatasource</I> interface is to work with RDF triples inside a datasource, allowing you to change that datasource's RDF graph.
  524: <H4><A NAME="77092"></A> Assertion and removal</H4>
  525: <P>Recall from the <!--INDEX triples:nsIRDFDataSource interface -->  <A HREF="#77065">"RDF triples: subject, predicate, and object</A>" section, earlier in this chapter, that triples are RDF statements in which the relationship between the subject, predicate, and object is more strictly defined. In the interface code, a triple's elements are all typically defined as resources rather than plain URIs, which means they can be asserted into a datasource in the particular sequence that makes them meaningful as parts of a triple:
  526: <PRE>rootSubject = RDF.GetResource('urn:root');
  527: predicate = RDF.GetResource('<A HREF=""></A>#chapters');
  528: object = RDF.GetResource('Chapter1');
  529: datasource.Assert(rootSubject,predicate,object,true);</PRE>
  530: <P>Once you assert the statement's elements into the datasource in this way, the datasource contains the triple. The <TT>truth</TT> value parameter in the last slot indicates that the given node is "locked" and thus cannot be overwritten.
  531: <P>Removing a triple from the datasource is as easy as adding it. If you try to remove a triple that doesn't exist, your request is ignored and no error messages are raised. To unassert a triple in the datasource, use:
  532: <PRE>rootSubject = RDF.GetResource('urn:root');
  533: predicate = RDF.GetResource('<A HREF=""></A>#chapters');
  534: object = RDF.GetResource('Chapter8');
  535: datasource.Unassert(rootSubject,predicate,object);</PRE>
  536: <H4><A NAME="77093"></A> Changing values</H4>
  537: <P>Changing values  <!--INDEX literals:values, changing -->  <!--INDEX datasources:values, changing --> in a datasource is also very easy. Assert and change a literal in the datasource as follows:
  538: <PRE>subject = RDF.GetResource('Chapter1');
  539: predicate = RDF.GetResource('<A HREF=""></A>#title');
  540: object = RDF.GetLiteral('Mozilla as a Platform');
  541: datasource.Assert(subject,predicate,object,true);
  542: newObject = RDF.GetLiteral('Mozilla is a cool Platform!');
  543: datasource.Change(subject,predicate,newObject,);</PRE>
  544: <P>If working with triples seems hard in the template generation, their use in these examples-where adding to and changing the parts is so easy-may make things clearer.
  545: <H4><A NAME="77094"></A> Moving triples</H4>
  546: <P>Moving a triple <!--INDEX triples:moving -->  in a datasource also requires some simple code. This example moves the asserted triple in the previous section:
  547: <PRE>newSubject = RDF.GetResource('Chapter99');
  548: // Moving from Chapter1 to Chapter99
  549: datasource.Move(subject,newSubject,predicate,object);</PRE>
  550: <H4><A NAME="77095"></A> HasAssertion</H4>
  551: <P>This next example <!--INDEX HasAssertion function -->  checks if the previous statement still exists in the datasource.
  552: <PRE>datasource.HasAssertion(newSubject,predicate,object,true);</PRE>
  553: <P>This function is useful when you create new statements and resources and want to make sure you are not overwriting pre-existing resources.
  554: <H4><A NAME="77096"></A> GetTarget</H4>
  555: <P>The <TT> <!--INDEX GetTarget method --> GetTarget</TT> method returns the resource's property value (i.e., the object). Given the RDF statement "(Eric) wrote (a book)," for example, the <TT>GetTarget</TT> method would input "Eric" and "wrote" and get back the object "a book." Once again, the example code is based on the previous examples:
  556: <PRE>object = datasource.GetTarget(newSubject,predicate,true);
  557: objects = datasource.GetTargets(rootSubject,predicate,true);
  558: // objects is an nsIEnumeration of the object and its properties</PRE>
  559: <P>In addition to <TT>GetTarget</TT>, as seen above, a <TT>GetTargets</TT> function returns an object and its properties in an enumeration. This function can be very handy for quick access to resources with fewer function calls.
  560: <H4><A NAME="77097"></A> GetSource</H4>
  561: <P><TT> <!--INDEX GetSource method --> GetSource</TT> is the inverse of <TT>GetTarget</TT>. Whereas <TT>GetTarget</TT> returns an object, <TT>GetSource</TT> returns the subject attached to an object. Given the RDF statement "(Eric) wrote (a book)" again, in other words, the <TT>GetSource</TT> method would input "wrote" and "a book" and get back the statement subject "Eric."
  562: <PRE>subject = datasource.GetSource(object,predicate,true);
  563: subjects = datasource.GetSources(object,predicate,true);
  564: // subjects is an nsIEnumeration of the subject and its properties</PRE>
  565: <P>When you create RDF statements with assertions or work with in-memory datasources, it is often difficult to remember the shape of the graph, which statements exist about which resources, or which objects are attached to which subjects. These "getter" methods can help you verify the shape of your graph.
  566: <H3><A NAME="77098"></A> nsIRDFRemoteDataSource</H3>
  567: <P>The <!--INDEX nsIRDFRemoteDataSource interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFRemoteDataSource -->  <!--INDEX interfaces:RDF:nsIRDFRemoteDataSource -->  <A HREF="#77084">"nsIRDFService</A>" section (earlier in this chapter) showed how to load a datasource from a remote server simply. If you want control over that datasource, you can manage it by using the <I>nsIRDFRemoteDatasource</I> to set up a remote datasource:
  568: <PRE>xml = ';1?name=xml-datasource';
  569: datasource = Components.classes[xml].
  570: createInstance(Components.interfaces.nsIRDFRemoteDataSource);
  571: datasource.Init('<A HREF=""></A>');
  572: datasource.Refresh(false);</PRE>
  573: <P>In this example, the <TT>Init</TT> and <TT>Refresh</TT> methods control the datasource on the server. In addition to these methods, you can call the <TT>Flush</TT> method to flush the data that's been changed and reload, or you can check whether the datasource is loaded by using the <TT>loaded</TT> property:
  574: <PRE>if (datasource.loaded) {
  575: // Do something
  576: }</PRE>
  577: <P>Built-in datasources that implement <I>nsIRDFRemoteDataSource</I> (and other necessary interfaces) and do their own data handling include:
  578: <PRE>;1?name=history
  583: <H3><A NAME="77099"></A> nsIRDFPurgeableDataSource</H3>
  584: <P>Using  <!--INDEX nsIRDFPurgeableDataSource interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFPurgeableDataSource -->  <!--INDEX interfaces:RDF:nsIRDFPurgeableDataSource --> the <I>nsIRDFPurgeableDatasource</I> interface allows you to delete a whole section of an existing in-memory datasource in one fell swoop. This means that all relatives-all statements derived from that node-are removed. When you work with large in-memory datasources (such as email systems), the using interface can manipulate the data efficiently. The <TT>Sweep( )</TT> method can delete a section that is marked in the datasource.
  585: <PRE>datasource.
  586: QueryInterface(Components.interfaces.nsIRDFPurgeableDataSource);
  587: rootSubject = RDF.GetResource('urn:root');
  588: predicate = RDF.GetResource('<A HREF=""></A>#chapters');
  589: object = RDF.GetResource('Chapter1');
  590: datasource.Mark(rootSubject,predicate,object,true);
  591: datasource.Sweep( );</PRE>
  592: <P>In this instance, a statement about a chapter in a book is marked and then removed from the datasource. You can also mark more than one node before sweeping.
  593: <H3><A NAME="77100"></A> nsIRDFNode, nsIRDFResource, and nsIRDFLiteral</H3>
  594: <P>These types of objects come from only a few different places. Here are all the functions that can return the resource of a literal:
  595: <PRE>nsIRDFService.GetResource
  596: nsIRDFService.GetAnonymousResource
  597: nsIRDFService.GetLiteral
  598: nsIRDFDataSource.GetSource
  599: nsIRDFDataSource.GetTarget</PRE>
  600: <P><I>nsIRDFNode <!--INDEX nsIRDFNode interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFNode -->  <!--INDEX interfaces:RDF:nsIRDFNode --> </I> is the parent of <I>nsIRDFResource</I> and <I>nsIRDFLiteral</I>. It is not used often because it's sole function is to test equality:
  601: <PRE>isEqual = resource1.EqualsNode(resource2);</PRE>
  602: <P>The other two interfaces inherit this function automatically. <TT>EqualsNode</TT> tests the equivalency of two resources, which can be useful when you try to put together different statements (e.g., "Eric wrote a book" and "[This] book is about XML") and want to verify that a resource like "book" is the same in both cases.
  603: <H4><A NAME="77101"></A> nsIRDFResource</H4>
  604: <P>Like <!--INDEX nsIRDFResource interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFResource -->  <!--INDEX interfaces:RDF:nsIRDFResource -->  <I>nsIRDFNode</I>, <I>nsIRDFResource</I> is a minimalist interface. Here are the functions and the property available in a resource from the <I>nsIRDFResource</I> interface:
  605: <PRE>resource = RDF.GetAnonymousResource( );
  606: // get the resource value, something like 'rdf:#$44RG7'
  607: resourceIdentifierString = resource.Value;
  608: // compare the resource to an identifier
  609: isTrue = resourceEqualsString(resourceIdentifierString);
  610: // Give the resource a real name.
  611: resource.Init('Eric');</PRE>
  612: <H4><A NAME="77102"></A> nsIRDFLiteral</H4>
  613: <P>A literal's  <!--INDEX nsIRDFLiteral interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFLiteral -->  <!--INDEX interfaces:RDF:nsIRDFLiteral --> value can be read but not written. To change the value of a literal, make a new literal and set it properly:
  614: <PRE>aValue = literal.Value;</PRE>
  615: <P>Note that <TT>aValue</TT> could be a string or an integer in this case. The base type conversion, based on the data's format, is done automatically.
  616: <H3><A NAME="77103"></A> nsIRDFContainerUtils</H3>
  617: <P>This interface <!--INDEX nsIRDFContainerUtils interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFContainerUtils -->  <!--INDEX interfaces:RDF:nsIRDFContainerUtils -->  facilitates the creation of containers and provides other container-related functions. It provides functions that make and work with a <TT>sequence</TT>, <TT>bag</TT>, and <TT>alternative</TT>. (The functions work the same way for all types of containers, so only <TT>sequence</TT> is covered here.) To create an instance of <I>nsIRDFContainerUtils</I>, use the following:
  618: <PRE>containerUtils = Components.classes[';1'
  619: getService(Components.interfaces.nsIRDFContainerUtils);</PRE>
  620: <P>Once you create an anonymous resource, you can create a sequence from it. Then you can test the type of the container and see whether it's empty:
  621: <PRE>// create an anonymous resource
  622: anonResource = RDF.GetAnonymousResource( );
  623: // create a sequence from that resource
  624: aSequence = containerUtils.MakeSeq(datasource,anonResource);
  625: // test the resource
  626: // (all of these are true)
  627: isContainer = containerUtils.isContainer(datasource,anonResource);
  628: isSequence = containerUtils.isSequence(datasource,anonResource);
  629: isEmpty = containerUtils.isEmpty(datasource,anonResource);</PRE>
  630: <P>Note that the sequence object is not passed into the functions performing the test in the previous example; the resource containing the sequence is passed in. Although <TT>aSequence</TT> and <TT>anonResource</TT> are basically the same resource, their data types are different. <TT>isContainer</TT>, <TT>isSequence</TT>, and <TT>isEmpty</TT> can be used more easily with other RDF functions when a resource is used as a parameter:
  631: <PRE>object = datasource.GetTarget(subject,predicate,true);
  632: if(RDF.isAnonymousResource(object))
  633: {
  634: isSeq = containerUtils.IsSeq(datasource,object);
  635: }</PRE>
  636: <P>The RDF container utilities also provide an indexing function. <TT>indexOf</TT> is useful for checking if an element exists in a container resource:
  637: <PRE>indexNumber =
  638: containerUtils.indexOf(datasource,object,RDF.GetLiteral('Eric'));
  639: if(index != -1)
  640: alert('Eric exists in this container');</PRE>
  641: <H3><A NAME="77104"></A> nsIRDFContainer</H3>
  642: <P>This interface  <!--INDEX nsIRDFContainer interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFContainer -->  <!--INDEX interfaces:RDF:nsIRDFContainer --> provides vector-like access to an RDF container's elements.<A NAME="b291"></A><A HREF="#291">[*]</A> The <I>nsIRDFContainer</I> interface allows you to add, look up, and remove elements from a container once you create it.
  643: <H4><A NAME="77105"></A> Adding an element to a container</H4>
  644: <P>You can add an <!--INDEX containers:elements, adding -->  <!--INDEX elements:containers, adding to -->  element to a container in two ways. You can append it to the end of the list with <TT>Append</TT> or insert it at a specific place in the container:
  645: <PRE>newLiteral = RDF.GetLiteral('Ian');
  646: aSequence.AppendElement(newLiteral);
  647: // or
  648: aSequence.InsertElementAt(newLiteral,3,true);</PRE>
  649: <P>The second attribute in <TT>InsertElementAt</TT> is where the element should be placed. The third attribute specifies that the list can be reordered. This method is useful for working with ordered containers such as sequences. If this locking parameter is set to false and an element already exists at that location, then the existing element is overwritten.
  650: <H4><A NAME="77106"></A> Removing an element from a container</H4>
  651: <P>Removing an element from a container works much the same as adding one. The difference is that a reordering attribute is included on <TT>RemoveElement</TT>. If this attribute is set to false, you may have holes in the container, which can create problems when enumerating or indexing elements within.
  652: <PRE>newLiteral = RDF.GetLiteral('Ian');
  653: aSequence.RemoveElement(newLiteral,true);
  654: // or
  655: aSequence.RemoveElementAt(newLiteral,3,true);</PRE>
  656: <P>If you use the <TT>indexOf</TT> property of <TT>nsIRDFContainer</TT>, you can also use <TT>GetCount</TT> to learn how many elements are in the container. The count starts at 0 when the container is initialized:
  657: <PRE>numberOfElements = aSequence.GetCount( );</PRE>
  658: <P>Once you have the sequence, the datasource and resource the sequence resides in can be retrieved. In effect, these properties look outward instead of toward the data:
  659: <PRE>seqDatasource = aSequence.DataSource;
  660: seqResource = aSequence.Resource;</PRE>
  661: <P>Like many methods in the RDF interfaces, this one allows you to traverse and retrieve any part of the RDF graph.
  662: <H3><A NAME="77107"></A> nsIRDFXML Interfaces</H3>
  663: <P>The RDF/XML interfaces are covered only briefly here. Besides being abstract and confusing, these interfaces require a lot of error handling to work correctly. Fortunately, a library on called <I>JSLib</I> handles RDF file access. The <I>JSLib</I> XML library does the dirty work in a friendly manner. See the section <A HREF="#77112">"JSLib RDF Files</A>," later in this chapter, for more information.
  664: <H4><A NAME="77108"></A> nsIRDFXMLParser and nsIRDFXMLSink</H4>
  665: <P><I>nsIRDFXML</I>  <!--INDEX nsIRDFXMLParser interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFXMLParser -->  <!--INDEX interfaces:RDF:nsIRDFXMLParser --> is the raw RDF/XML parser of Mozilla. Used by Mozilla, its main purpose is to parse an RDF file  <!--INDEX parsing:RDF files --> asynchronously as a stream listener. Though this subject is beyond the scope of this book, the interface provides something interesting and useful. The <TT>parseString</TT> function allows you to feed <I>nsIRDFXMLParser</I> a string and have it parse that data as RDF and put it into a datasource, as <A HREF="#77042">Example 10-9</A> demonstrates.
  667: <P><I>Example 10-9: <A NAME="77042"></A></I>
  668: <I>Parse an RDF/XML string into a datasource</I>
  669: <PRE> RDF = Components.classes</TD>[';1'].
  670:          getService(Components.interfaces.nsIRDFService);
  671:  // Used to create a URI below
  672:  ios = Components.classes</TD>[";1"].
  673:        getService(Components.interfaces.nsIIOService);
  674:  xmlParser = ';1';
  675:  parser = Components.classes</TD>[xmlParser].
  676:           createInstance(Components.interfaces.nsIRDFXMLParser);
  677:  uri = ios.newURI("<A HREF=""></A>#", null);
  678:  // Entire RDF File stored in a string
  679:  rdfString =
  680:    '&lt;rdf:RDF xmlns:rdf=</TD><I><A HREF=""></A>#</I>' +
  681:    'xmlns:b="<A HREF=""></A>#"&gt;' +
  682:    '&lt;rdf:Description about="urn:root"&gt;' + // Rest of file ...
  683:  parser.parseString(datasource,uri,rdfString);
  684:  // Parsed string data now resides in the datasource</PRE>
  686: <P>The RDF/XML data that was in the string is a part of the datasource and ready for use (just like any other RDF data in a datasource). The <TT>uri</TT> acts as a base reference for the RDF in case of relative links.
  687: <P><I>nsIRDFXMLParser</I> uses <I>nsIRDFXMLSink</I>  <!--INDEX nsIRDFXMLSink interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFXMLSink -->  <!--INDEX interfaces:RDF:nsIRDFXMLsink --> for event  <!--INDEX event handling:RDF files --> handling. The interfaces are totally separate, but behind the scenes, they work together with the incoming data. <A HREF="#77044">Example 10-10</A> shows how a series of events is created in an object and then used to handle parser events.
  689: Example 10-10<A NAME="77044"></A>
  690: <I>Setup nsIRDFXMLSink with event handlers</I>
  691: <PRE> var Observer = {
  692:     onBeginLoad: function(aSink)
  693:     {
  694:       alert("Beginning to load the RDF/XML...");
  695:     },
  696:     onInterrupt: function(aSink) {},
  697:     onResume: function(aSink) {},
  698:     onEndLoad: function(aSink)
  699:     {
  700:       doneLoading( ); // A function that does something with the datasource
  701:     },
  702:    onError: function(aSink, aStatus, aErrorMsg)
  703:    {
  704:      alert("Error: " + aErrorMsg);
  705:    }
  706:  };</PRE>
  708: <P>Once the event handlers are set up, you can use <I>nsIRDFXMLSink</I>:
  709: <PRE>sink = datasource.QueryInterface(Components.interfaces.nsIRDFXMLSink);
  710: sink.addXMLSinkObserver(observer);</PRE>
  711: <P>The events are then triggered automatically when the datasource is loaded up with data, allowing you to create handlers that manipulate the data as it appears.
  712: <H4><A NAME="77109"></A> nsIRDFXMLSerializer and nsIRDFXMLSource</H4>
  713: <P>These two <!--INDEX nsIRDFXMLSerializer interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFXMLSerializer -->  <!--INDEX interfaces:RDF:nsIRDFXMLSerializer -->  interfaces are meant to work together. <I>nsIRDFXMLSerializer</I> lets you <TT>init</TT> a datasource into the <TT>xml-serializer</TT> module that outputs RDF. However, <I> <!--INDEX nsIRDFXMLSource interface -->  <!--INDEX RDF (Resource Description Framework):interfaces:nsIRDFXMLSource -->  <!--INDEX interfaces:RDF:nsIRDFXMLSource --> nsIRDFXMLSource</I> actually contains the <TT>Serialize</TT> function. Here's how to serialize a datasource into an alert:
  714: <PRE>serializer = ';1';
  715: s = Components.classes[serializer].
  716: createInstance(Components.interfaces.nsIRDFXMLSerializer);
  717: s.init(datasource);
  718: output = new Object( );
  719: output.write = new function(buf,count)
  720: {
  721: alert(buf); // Show the serialized syntax
  722: return count;
  723: }
  724: s.QueryInterface(Components.interfaces.nsIRDFXMLSource).Serialize(output);</PRE>
  725: <P>As in the previous example with <I>nsIRDFXMLParser</I>, <A HREF="#77044">Example 10-10</A> does not use RDF data from a file. The serialized data is passed directly to an alert, which then displays the generated RDF.
  726: <H2><A NAME="77110"></A> Template Dynamics</H2>
  727: <P>Once you learn how to create templates and modify datasources, the ultimate in template mastery is to apply datasources to a template dynamically.
  728: <P>This process is done through the <TT>database</TT> property of a XUL element that contains a template. The object returned by this property has only two methods, <TT>AddDataSource</TT> and <TT>RemoveDataSource</TT>. A separate <TT>builder.rebuild</TT> function is also available for refreshing the template's display, but you probably won't need it once the template automatically updates itself. The addition and removal of a datasource to a <TT>&lt;tree&gt;</TT> template is demonstrated here:
  729: <PRE>tree = document.getElementById('tree-template');
  730: tree.database.AddDataSource(someDatasource);
  731: // tree will now update its display to show contents
  732: tree.database.RemoveDataSource(someDatasource);
  733: // tree will now be empty
  734: // Optional, use only when tree is not updating for some reason
  735: tree.builder.rebuild( );</PRE>
  736: <P>You can add and remove any datasource as long as the template actually matches the data inside it. Also, multiple datasources can be applied to the same template with no problems, which allows you to aggregate data from different places, such as contact data, work information, and computer hardware information (e.g., "Eric uses a Compaq with the serial number 1223456-1091 to write his book and he sits on the fourth floor of the Acme Building, which is the Bay Area branch of Acme Enterprises.)
  737: <H3><A NAME="77111"></A> Template Dynamics in XBL</H3>
  738: <P>Putting templates  <!--INDEX XBL (eXtensible Binding Language):templates -->  <!--INDEX templates:XBL -->  <!--INDEX datasources:templates --> inside XBL can be a useful organizational scheme. Here is a basic implementation of a widget that creates a list of people based on names listed in an attribute:
  739: <PRE>&lt;people names="Brian King,Eric Murphy,Ian Oeschger,Pete Collins,David Boswell"/&gt;</PRE>
  740: <P>Obviously, the comma is used as the delimiter for this list. The constructor element in <A HREF="#77046">Example 10-11</A> uses JavaScript to break up this string.
  742: Example 10-11<A NAME="77046"></A>
  743: <I>Binding with in-memory datasource and &lt;listbox&gt; template</I>
  744: <PRE> &lt;?xml version="1.0"?&gt;
  745:  &lt;bindings xmlns ="<A HREF=""></A>"
  746:  xmlns:xul="<A HREF=""></A>"&gt;
  747:    &lt;binding id="people"&gt;
  748:      &lt;implementation&gt;
  749:        &lt;constructor&gt;
  750:        &lt;!</TD>[CDATA[
  751:          // Read the Names into an Array
  752:          names = document.getAnonymousNodes(this)</TD>[0].getAttribute('names');
  753:          names = new String(names);
  754:          namesArray= names.split(',');
  755:          // Initialize the RDF Service
  756:          rdf = Components
  757:               .classes</TD>[';1']
  758:               .getService(Components.interfaces.nsIRDFService);
  759:          // Initialize a Datasource in Memory
  760:               inMemory = ';1?name=in-memory-datasource';
  761:          datasource = Components.classes</TD>[inMemory].
  762:             createInstance(Components.interfaces.nsIRDFDataSource);
  763:          // Create the Root Node and an Anonymous Resource to Start With
  764:          root   = rdf.GetResource('urn:root');
  765:          people = rdf.GetAnonymousResource( );
  766:          // Insert the People resource into the RDF graph
  767:          datasource.Assert
  768:            (root,
  769:             rdf.GetResource('<A HREF=""></A>#people'),
  770:             people,true);
  771:          // Initialize Methods needed for Containers
  772:          rdfc = Components
  773:                .classes</TD>[';1']
  774:                .getService(Components.interfaces.nsIRDFContainerUtils);
  775:          // For the People resource, make a Sequence of people
  776:          peopleSequence = rdfc.MakeSeq(datasource, people);
  777:          for(i=0;i&lt;namesArray.length;i++)
  778:          {
  779:            // Create a Person, with a Unique Number, for example
  780:            person = rdf.GetResource(i);
  781:            // Insert the Person's name into the RDF graph underneath number
  782:            datasource.Assert
  783:              (person,
  784:               rdf.GetResource('<A HREF=""></A>#name'),
  785:               rdf.GetLiteral(namesArray</TD>[i]),true);
  786:            peopleSequence.AppendElement(person);
  787:          }
  788:          list = document.getAnonymousNodes(this)</TD>[1];
  789:          list.database.AddDataSource(datasource);
  790:        ]]&gt;
  791:        &lt;/constructor&gt;
  792:      &lt;/implementation&gt;
  793:      &lt;content&gt;
  794:        &lt;xul:box id="names" inherits="names" flex="0"/&gt;
  795:        &lt;xul:listbox datasources="rdf:null" ref="urn:root" flex="1"&gt;
  796:          &lt;xul:template&gt;
  797:            &lt;xul:rule&gt;
  798:              &lt;xul:conditions&gt;
  799:                &lt;xul:content uri="?uri"/&gt;
  800:                &lt;xul:triple subject="?uri"
  801:                         predicate="<A HREF=""></A>#people"                              object="?people"/&gt;
  802:                &lt;xul:member container="?people" child="?person"/&gt;
  803:                &lt;xul:triple subject="?person"
  804:                         predicate="<A HREF=""></A>#name"                         object="?name"/&gt;
  805:              &lt;/xul:conditions&gt;
  806:              &lt;xul:action&gt;
  807:                &lt;xul:listitem uri="?person"&gt;
  808:                  &lt;xul:listcell&gt;
  809:                    &lt;xul:description value="?person "/&gt;
  810:                    &lt;xul:description value="?name"/&gt;
  811:                  &lt;/xul:listcell&gt;
  812:                &lt;/xul:listitem&gt;
  813:              &lt;/xul:action&gt;
  814:            &lt;/xul:rule&gt;
  815:          &lt;/xul:template&gt;
  816:        &lt;/xul&gt;
  817:      &lt;/content&gt;
  818:    &lt;/binding&gt;
  819:  &lt;/bindings&gt;</PRE>
  821: <P>In <A HREF="#77046">Example 10-11</A>, everything you need to display a datasource dynamically is present. The only difference between this dynamically generated version and a static RDF-based template is the <TT>datasources="rdf:null"</TT>, which specifies that the template does not refer to an actual datasource. Data that is edited, rearranged, or changed in a different way is often displayed dynamically in the UI with templates in this manner.
  822: <H2><A NAME="77112"></A> JSLib RDF Files</H2>
  823: <P>Working  <!--INDEX STARTRANGE--RDF (Resource Description Framework):files:JSLib -->  <!--INDEX STARTRANGE--JSLib libraries:RDF files -->  <!--INDEX STARTRANGE--files:RDF:JSLib --> with actual RDF files is not easy. However, JSLib (<I><A HREF=""></A></I>) provides an RDF file library that can help you develop an RDF-based application. The library provides many types of error checking, as well as a friendly abstraction away from the RDF/XML interfaces of Mozilla (see <A HREF="#77107">"nsIRDFXML Interfaces</A>," later in this chapter). <A HREF="#77048">Example 10-12</A> shows some common uses of the <TT>RDFFile</TT> class in JSLib. This functionality can be used in situations in which you have data in RDF that you want to pull out "manually" and use piece by piece (rather than as a whole datasource in a template).
  825: Example 10-12<A NAME="77048"></A>
  826: <I>Creating and modifying an RDF file using JSLib</I>
  827: <PRE> var rdfFileURL = 'chrome://jarfly/content/jar.rdf';
  828:  var gTreeBody = null;
  829:  var gListbox = null;
  830:  var gRDF = null;
  831:  function onload( )
  832:  {
  833:    fileUtils = new FileUtils( );
  834:    path = fileUtils.chrome_to_path(rdfFileURL);
  835:    if(navigator.platform == "Win32") {
  836:      path = path.replace(/\//g,"\\");
  837:      // Only needed on Windows, until JSLib is fixed
  838:    }
  839:    gRDF = new RDFFile(path,'jar:flies','<A HREF=""></A>#');
  840:    gTreeBody = document.getElementById('tb');
  841:    gTreeBody.database.AddDataSource(gRDF.dsource);
  842:    gListbox  = document.getElementById('list');
  843:    gListbox.database.AddDataSource(gRDF.dsource);
  844:    rebuildLists( );
  845:  }
  846:  function rebuildLists( )
  847:  {
  848:    gTreeBody.builder.rebuild( );
  849:    gListbox.builder.rebuild( );
  850:  }
  851:  function update( )
  852:  {
  853:    name      = document.getElementById('nameField').value;
  854:    color     = document.getElementById('colorField').value;
  855:    quantity  = document.getElementById('quantityField').value;
  856:    seqNumber = -1;
  857:    del       = false;
  858:    replace   = false;
  859:    if(document.getElementById('delete').checked)
  860:      del = true;
  861:    if(document.getElementById('replace').checked)
  862:      replace = true;
  863:    var seqLength = 0;
  864:    if(gRDF.doesSeqExist('types'))
  865:    {
  866:      seqLength = gRDF.getSeqSubNodes('types').length;
  867:      //if(del)gRDF.removeSeq('types',false);
  868:    }
  869:    else
  870:      gRDF.addSeq('types');
  871:    for(i=0;i&lt;seqLength;i++)
  872:    {
  873:      tempItem = 'types:_' + (i+1);
  874:      if(gRDF.getAttribute(tempItem,'name')==name)
  875:        seqNumber = gRDF.getAttribute(tempItem,'number');
  876:    }
  877:    if(seqNumber == -1)
  878:    {
  879:      item = 'types:_' + (seqLength+1);
  880:      gRDF.setAttribute(item,'name',name);
  881:      gRDF.setAttribute(item,'number',seqLength+1);
  882:    }
  883:    else
  884:    {
  885:      item = 'types:_' + seqNumber;
  886:      gRDF.setAttribute(item,'number',seqNumber);
  887:    }
  888:    if(color!='')
  889:      gRDF.setAttribute(item,'color',color);
  890:    if(quantity!='')
  891:    {
  892:      gRDF.setAttribute(item,'quantity',quantity);
  893:      gRDF.setAttribute(item,'dead',calcDead(quantity,replace));
  894:    }
  895:    if(!del)
  896:      gRDF.addNode(item);
  897:    else
  898:      gRDF.removeNode(item);
  899:    gRDF.flush( );
  900:    onload( );
  901:  }
  902:  function calcDead(quantity,replace)
  903:  {
  904:    if(!replace)
  905:    {
  906:      v = parseInt( (quantity * Math.random( )) * 0.13 );
  907:      return (v.toString( ));
  908:    }
  909:    else
  910:      return 0;
  911:  }
  912:  function changeC(color)
  913:  {
  914:    document.getElementById('colorField').value=color;
  915:  }
  916:  function changeQ(quantity)
  917:  {
  918:    document.getElementById('quantityField').value=quantity;
  919:  }</PRE>
  921: <P>This example contains a datasource that represents a collection of flies. These flies are built up dynamically with JavaScript objects from the RDF library, which represent the datasource itself (<TT>gRDF = new RDFFile</TT>), methods that view and update the data (<TT>if(gRDF.getAttribute(tempItem,'name')==name</TT>), and utilities that make work with RDF files easier (<TT>path = fileUtils.chrome_to_path(rdfFileURL)</TT>).
  922: <P><A HREF="#77050">Example 10-13</A> initializes and updates a file after it changes.
  924: Example 10-13<A NAME="77050"></A>
  925: <I>Initialization</I>
  926: <PRE> var rdfFileURL = 'chrome://jarfly/content/jar.rdf';
  927:  var gTreeBody = null;
  928:  var gListbox = null;
  929:  var gRDF = null;
  930:  function onload( )
  931:  {
  932:    fileUtils = new FileUtils( );
  933:    path = fileUtils.chrome_to_path(rdfFileURL);
  934:    if(navigator.platform == "Win32") {
  935:      path = path.replace(/\//g,"\\");
  936:      // Only needed on Windows, until JSLib is fixed
  937:    }
  938:    gRDF = new RDFFile(path,'jar:flies','<A HREF=""></A>#');</PRE>
  940: <P>In <A HREF="#77050">Example 10-13</A>, the file URL is set to an RDF file in the chrome area. Note that both a <TT>&lt;tree&gt;</TT> and a <TT>&lt;listbox&gt;</TT>, which display the same data in different ways, will be updated with the same datasource. The <TT>onload</TT> function is called after the main XUL document is loaded. A class called <TT>FileUtils</TT> is initialized, which will create a path to the RDF file. If the file doesn't already exist, JSLib automatically creates it.
  941: <P>Finally, the <TT>RDFFile</TT> is created by using the path and a root resource identifier, and the "xFly" namespace is used for the data references. <A HREF="#77052">Example 10-14</A> shows that the RDF file is ready to have its data added and deleted.
  943: Example 10-14<A NAME="77052"></A>
  944: <I>Data updating</I>
  945: <PRE> function update( )
  946:  {
  947:    ...
  948:    var seqLength = 0;
  949:    if(gRDF.doesSeqExist('types'))
  950:    {
  951:      seqLength = gRDF.getSeqSubNodes('types').length;
  952:      //if(del)gRDF.removeSeq('types',false);
  953:    }
  954:    else
  955:      gRDF.addSeq('types');
  956:    for(i=0;i&lt;seqLength;i++)
  957:    {
  958:      tempItem = 'types:_' + (i+1);
  959:      if(gRDF.getAttribute(tempItem,'name')==name)
  960:        seqNumber = gRDF.getAttribute(tempItem,'number');
  961:    }
  962:    if(seqNumber == -1)
  963:    {
  964:      item = 'types:_' + (seqLength+1);
  965:      gRDF.setAttribute(item,'name',name);
  966:      gRDF.setAttribute(item,'number',seqLength+1);
  967:    }
  968:    else
  969:    {
  970:      item = 'types:_' + seqNumber;
  971:      gRDF.setAttribute(item,'number',seqNumber);
  972:    }
  973:    if(color!='')
  974:      gRDF.setAttribute(item,'color',color);
  975:    if(quantity!='')
  976:    {
  977:      gRDF.setAttribute(item,'quantity',quantity);
  978:      gRDF.setAttribute(item,'dead',calcDead(quantity,replace));
  979:    }
  980:    if(!del)
  981:      gRDF.addNode(item);
  982:    else
  983:      gRDF.removeNode(item);
  984:    gRDF.flush( );
  985:    onload( );</PRE>
  987: <P><A HREF="#77052">Example 10-14</A> contains a modified version of the <TT>update</TT> function. First, the function checks to see if a sequence called <TT>types</TT> is in the RDF file. If not, it creates one. Next, it appends an item to the sequence using <TT>type:_+(seqLength+1)</TT>. The same type of container setup was described in the section <A HREF="#77104">"nsIRDFContainer</A>," earlier in this chapter.
  988: <P>The <TT>update</TT> function then adds the color, quantity, and "dead" properties of that new item in the sequence. Next, it ensures that you actually want to add the item to the RDF file and flushes it out if not. It then recalls the <TT>onload</TT> function to update the template display.
  989: <P>These are the basics of using <TT>RDFFile</TT>. As you can see, using JSLib for RDF is often much easier than trying to implement a similar setup on your own. More information about <TT>RDFFile</TT> and the other JSLib libraries can  <!--INDEX web sites:JSLib --> be <!--INDEX ENDRANGE--RDF (Resource Description Framework):files:JSLib -->  <!--INDEX ENDRANGE--JSLib libraries:RDF files -->  <!--INDEX ENDRANGE--files:RDF:JSLib -->  found at <I><A HREF=""></A></I>.
  990: <H2><A NAME="77113"></A> Manifests</H2>
  991: <P>The package  <!--INDEX RDF (Resource Description Framework):manifest files -->  <!--INDEX manifests:RDF --> descriptions, generally called <I>manifests</I>, use RDF to describe new packages and files to Mozilla. They can be added seamlessly because RDF provides a platform-like environment that facilitates the installation and use of new Mozilla software.
  992: <P>All packages, including the ones that come preinstalled with Mozilla (such as the browser, the MailNews component, and the en-US language pack), have manifests describing them in terms of their relation to other packages. The manifests are typically files called <I>contents.rdf</I>, but they may also be called <I>manifest.rdf</I>. <A HREF="#77054">Example 10-15</A> presents a <I>contents.rdf</I> file that describes a new skin for Mozilla.
  994: Example 10-15<A NAME="77054"></A>
  995: <I>Skin manifest</I>
  996: <PRE> &lt;?xml version="1.0"?&gt;
  997:  &lt;RDF:RDF xmlns:RDF="</TD><I><A HREF=""></A>#</I>"
  998:    xmlns:chrome="</TD><I><A HREF=""></A>#</I>"&gt;
  999:  &lt;!-- List all the skins being supplied by this theme --&gt;
 1000:  &lt;RDF:Seq about="urn:mozilla:skin:root"&gt;
 1001:    &lt;RDF:li resource="urn:mozilla:skin:modern/1.0" /&gt;
 1002:  &lt;/RDF:Seq&gt;
 1003:  &lt;!-- Modern Information --&gt;
 1004:  &lt;RDF:Description about="urn:mozilla:skin:modern/1.0"
 1005:    chrome:displayName="Modern"
 1006:    chrome:author="</TD><I><A HREF=""></A></I>"
 1007:    chrome:name="</TD><I><A HREF=""></A></I>"&gt;
 1008:  &lt;chrome:packages&gt;
 1009:    &lt;RDF:Seq about="urn:mozilla:skin:modern/1.0:packages"&gt;
 1010:      &lt;--RDF:li resource="urn:mozilla:skin:modern/1.0:aim"/ --&gt;
 1011:      &lt;RDF:li resource="urn:mozilla:skin:modern/1.0:communicator"/&gt;
 1012:      &lt;RDF:li resource="urn:mozilla:skin:modern/1.0:editor"/&gt;
 1013:      &lt;RDF:li resource="urn:mozilla:skin:modern/1.0:global"/&gt;
 1014:      &lt;RDF:li resource="urn:mozilla:skin:modern/1.0:messenger"/&gt;
 1015:      &lt;RDF:li resource="urn:mozilla:skin:modern/1.0:navigator"/&gt;
 1016:    &lt;/RDF:Seq&gt;
 1017:  &lt;/chrome:packages&gt;
 1018:  &lt;/RDF:Description&gt;
 1019:  &lt;/RDF:RDF&gt;</PRE>
 1021: <P>As you can see, the manifest is divided up into sections. After the preamble, where the XML processing instruction and the namespace declarations are made, an RDF sequence lists all the themes defined or supplemented (since you can create a package updated for only one Mozilla component, such as the browser) by this package. This section contains only one <TT>RDF:li-</TT>the modern theme.
 1022: <P>The next section gives more information on the theme, such as the author, the theme name, and a description. The <TT>chrome:packages</TT> structure that completes the manifest describes the packages to which this theme should be applied. All major components of the Netscape browser are listed in this example-including the AIM client that is not a part of Mozilla-but is skinned by themes such as Modern.
 1023: <H3><A NAME="77114"></A> RDF and Dynamic Overlays</H3>
 1024: <P>Manifests can <!--INDEX dynamic overlays:RDF -->  <!--INDEX overlays:RDF -->  <!--INDEX RDF (Resource Description Framework):manifest files:dynamic overalys and -->  <!--INDEX manifests:RDF:dynamic overlays and -->  also add new menu items to existing Mozilla menus. When you add a new package to Mozilla, you should make it accessible from within the browser application, where users can access it easily. This is where RDF and dynamic overlays come in.
 1025: <P>The RDF you provide in your package makes it possible for the chrome registry, discussed in <A HREF="ch06.html#77063">Chapter 6</A>, to find, 
 1026: understand, and register your new files. Packages must be registered if they are to be skinned, localized, or accessed using the special tools Mozilla provides (e.g., the chrome URL or XPConnect to the XPCOM libraries). If you do not register your package by providing the necessary RDF manifests, it cannot be accessed except as a disparate collection of files in the browser's main content window, which is not what you want.
 1027: <P>You can add overlays in Mozilla in two ways: import them explicitly by using an overlay processing instruction at the top of the XUL file into which items in the overlay file are to be "composed," or use RDF to register and load overlay files at runtime. This latter method will be used here to add an "xFly" item to the Tools menu of the Mozilla suite of applications.
 1028: <P><A HREF="#77056">Example 10-16</A> shows the <I>contents.rdf</I> manifest format that alerts Mozilla of the presence of an overlay, its target in the Mozilla application, and the package of which it is a part.
 1030: Example 10-16<A NAME="77056"></A>
 1031: <I>Overlay for a sample application menu</I>
 1032: <PRE> &lt;?xml version="1.0"?&gt;
 1033:  &lt;RDF:RDF xmlns:RDF="<A HREF=""></A>#"
 1034:           xmlns:chrome="<A HREF=""></A>#"&gt;
 1035:    &lt;RDF:Seq about="urn:mozilla:package:root"&gt;
 1036:      &lt;RDF:li resource="urn:mozilla:package:help"/&gt;
 1037:    &lt;/RDF:Seq&gt;
 1038:    &lt;RDF:Description about="urn:mozilla:package:help"
 1039:          chrome:displayName="xFly Application"
 1040:          chrome:author=""
 1041:          chrome:name="xfly"&gt;
 1042:    &lt;/RDF:Description&gt;
 1043:    &lt;!-- Declare overlay points used in this package --&gt;
 1044:    &lt;RDF:Seq about="urn:mozilla:overlays"&gt;
 1045:      &lt;RDF:li resource="chrome://communicator/content/tasksOverlay.xul" /&gt;
 1046:    &lt;/RDF:Seq&gt;
 1047:    </TD>&lt;RDF:Seq about="chrome://communicator/content/tasksOverlay.xul"&gt;
 1048:      &lt;RDF:li&gt;chrome://xfly/content/xflyOverlay.xul&lt;/RDF:li&gt;
 1049:    &lt;/RDF:Seq&gt;
 1050:  &lt;/RDF:RDF&gt;</PRE>
 1052: <P>The manifest in <A HREF="#77056">Example 10-16</A> names the file <I>xflyOverlay.xul</I> as an overlay. Then it names <I>tasksOverlay.xul</I> 
 1053: as the base file into which the contents are placed. In this case, the overlays can overlay other overlay files arbitrarily. An overlay can define new content anywhere in the application. Overlays are often responsible for putting new items in menus. As long as the target and overlay <TT>id</TT>s match, any two RDF datasources are merged. You can try this example by putting a single new menu item in an overlay structure like the one shown in <A HREF="#77058">Example 10-17</A>. Save it as <I>xflyOverlay.xul</I> in the <I>xfly</I> content subdirectory and use the manifest information in <A HREF="#77056">Example 10-16</A> as part of the packaging process described in <A HREF="ch06.html#77063">Chapter 6</A>.
 1055: Example 10-17<A NAME="77058"></A>
 1056: <I>Overlay for an xFly menu item in the browser</I>
 1057: <PRE> &lt;?xml version="1.0"?&gt;
 1058:  &lt;overlay id="xflyMenuID"
 1059:          xmlns:html="<A HREF=""></A>"
 1060:          xmlns="<A HREF=""></A>"&gt;
 1062:    &lt;menupopup id="tools_menu"&gt;
 1063:      &lt;menuitem label="xfly xml editor"
 1064:          oncommand="toOpenWindowByType('mozilla:xfly, 'chrome://xfly/content/');" /&gt;
 1066:  &lt;/menupopup&gt;
 1068:  &lt;/overlay&gt;</PRE>
 1070: <P>The <TT>menupopup</TT> in Mozilla with the ID "tools_menu" gets a new menu item when this overlay is processed and its content included.
 1071: <HR>
 1072: <HR><A NAME="291"></A><A HREF="#b291">[Back]</A>
 1073: <A NAME="77060"></A>
 1074: A vector, for those who don't know, is a flexible and
 1075: more accessible version of the array data structure.
 1076: <HR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
 1077: <!-- ?php require(NOTES); ? -->
 1078: <?php $post_to_list=NO; require(ANNOTATE); ?>
 1079: </BODY>
 1080: </HTML>

FreeBSD-CVSweb <>