helm/DEVEL/pxp/pxp/doc/manual/html/x1818.html

   1 <HTML
   2 ><HEAD
   3 ><TITLE
   4 >Invoking the parser</TITLE
   5 ><META
   6 NAME="GENERATOR"
   7 CONTENT="Modular DocBook HTML Stylesheet Version 1.46"><LINK
   8 REL="HOME"
   9 TITLE="The PXP user's guide"
  10 HREF="index.html"><LINK
  11 REL="UP"
  12 TITLE="Configuring and calling the parser"
  13 HREF="c1567.html"><LINK
  14 REL="PREVIOUS"
  15 TITLE="The DTD classes"
  16 HREF="x1812.html"><LINK
  17 REL="NEXT"
  18 TITLE="Updates"
  19 HREF="x1965.html"><LINK
  20 REL="STYLESHEET"
  21 TYPE="text/css"
  22 HREF="markup.css"></HEAD
  23 ><BODY
  24 CLASS="SECT1"
  25 BGCOLOR="#FFFFFF"
  26 TEXT="#000000"
  27 LINK="#0000FF"
  28 VLINK="#840084"
  29 ALINK="#0000FF"
  30 ><DIV
  31 CLASS="NAVHEADER"
  32 ><TABLE
  33 WIDTH="100%"
  34 BORDER="0"
  35 CELLPADDING="0"
  36 CELLSPACING="0"
  37 ><TR
  38 ><TH
  39 COLSPAN="3"
  40 ALIGN="center"
  41 >The PXP user's guide</TH
  42 ></TR
  43 ><TR
  44 ><TD
  45 WIDTH="10%"
  46 ALIGN="left"
  47 VALIGN="bottom"
  48 ><A
  49 HREF="x1812.html"
  50 >Prev</A
  51 ></TD
  52 ><TD
  53 WIDTH="80%"
  54 ALIGN="center"
  55 VALIGN="bottom"
  56 >Chapter 4. Configuring and calling the parser</TD
  57 ><TD
  58 WIDTH="10%"
  59 ALIGN="right"
  60 VALIGN="bottom"
  61 ><A
  62 HREF="x1965.html"
  63 >Next</A
  64 ></TD
  65 ></TR
  66 ></TABLE
  67 ><HR
  68 ALIGN="LEFT"
  69 WIDTH="100%"></DIV
  70 ><DIV
  71 CLASS="SECT1"
  72 ><H1
  73 CLASS="SECT1"
  74 ><A
  75 NAME="AEN1818"
  76 >4.4. Invoking the parser</A
  77 ></H1
  78 ><P
  79 >Here a description of Pxp_yacc.</P
  80 ><DIV
  81 CLASS="SECT2"
  82 ><H2
  83 CLASS="SECT2"
  84 ><A
  85 NAME="AEN1821"
  86 >4.4.1. Defaults</A
  87 ></H2
  88 ><P
  89 >The following defaults are available:
  90
  91 <PRE
  92 CLASS="PROGRAMLISTING"
  93 >val default_config : config
  94 val default_extension : ('a node extension) as 'a
  95 val default_spec : ('a node extension as 'a) spec</PRE
  96 ></P
  97 ></DIV
  98 ><DIV
  99 CLASS="SECT2"
 100 ><H2
 101 CLASS="SECT2"
 102 ><A
 103 NAME="AEN1825"
 104 >4.4.2. Parsing functions</A
 105 ></H2
 106 ><P
 107 >In the following, the term "closed document" refers to
 108 an XML structure like
 109
 110 <PRE
 111 CLASS="PROGRAMLISTING"
 112 >&lt;!DOCTYPE ... [ <TT
 113 CLASS="REPLACEABLE"
 114 ><I
 115 >declarations</I
 116 ></TT
 117 > ] &gt;
 118 &lt;<TT
 119 CLASS="REPLACEABLE"
 120 ><I
 121 >root</I
 122 ></TT
 123 >&gt;
 124 ...
 125 &lt;/<TT
 126 CLASS="REPLACEABLE"
 127 ><I
 128 >root</I
 129 ></TT
 130 >&gt;</PRE
 131 >
 132
 133 The term "fragment" refers to an XML structure like
 134
 135 <PRE
 136 CLASS="PROGRAMLISTING"
 137 >&lt;<TT
 138 CLASS="REPLACEABLE"
 139 ><I
 140 >root</I
 141 ></TT
 142 >&gt;
 143 ...
 144 &lt;/<TT
 145 CLASS="REPLACEABLE"
 146 ><I
 147 >root</I
 148 ></TT
 149 >&gt;</PRE
 150 >
 151
 152 i.e. only to one isolated element instance.</P
 153 ><P
 154 ><PRE
 155 CLASS="PROGRAMLISTING"
 156 >val parse_dtd_entity : config -&#62; source -&#62; dtd</PRE
 157 >
 158
 159 Parses the declarations which are contained in the entity, and returns them as
 160 <TT
 161 CLASS="LITERAL"
 162 >dtd</TT
 163 > object.</P
 164 ><P
 165 ><PRE
 166 CLASS="PROGRAMLISTING"
 167 >val extract_dtd_from_document_entity : config -&#62; source -&#62; dtd</PRE
 168 >
 169
 170 Extracts the DTD from a closed document. Both the internal and the external
 171 subsets are extracted and combined to one <TT
 172 CLASS="LITERAL"
 173 >dtd</TT
 174 > object. This
 175 function does not parse the whole document, but only the parts that are
 176 necessary to extract the DTD.</P
 177 ><P
 178 ><PRE
 179 CLASS="PROGRAMLISTING"
 180 >val parse_document_entity :
 181     ?transform_dtd:(dtd -&#62; dtd) -&#62;
 182     ?id_index:('ext index) -&#62;
 183     config -&#62;
 184     source -&#62;
 185     'ext spec -&#62;
 186         'ext document</PRE
 187 >
 188
 189 Parses a closed document and validates it against the DTD that is contained in
 190 the document (internal and external subsets). The option
 191 <TT
 192 CLASS="LITERAL"
 193 >~transform_dtd</TT
 194 > can be used to transform the DTD in the
 195 document, and to use the transformed DTD for validation. If
 196 <TT
 197 CLASS="LITERAL"
 198 >~id_index</TT
 199 > is specified, an index of all ID attributes is
 200 created.</P
 201 ><P
 202 ><PRE
 203 CLASS="PROGRAMLISTING"
 204 >val parse_wfdocument_entity :
 205     config -&#62;
 206     source -&#62;
 207     'ext spec -&#62;
 208         'ext document</PRE
 209 >
 210
 211 Parses a closed document, but checks it only on well-formedness.</P
 212 ><P
 213 ><PRE
 214 CLASS="PROGRAMLISTING"
 215 >val parse_content_entity  :
 216     ?id_index:('ext index) -&#62;
 217     config -&#62;
 218     source -&#62;
 219     dtd -&#62;
 220     'ext spec -&#62;
 221         'ext node</PRE
 222 >
 223
 224 Parses a fragment, and validates the element.</P
 225 ><P
 226 ><PRE
 227 CLASS="PROGRAMLISTING"
 228 >val parse_wfcontent_entity :
 229     config -&#62;
 230     source -&#62;
 231     'ext spec -&#62;
 232         'ext node</PRE
 233 >
 234
 235 Parses a fragment, but checks it only on well-formedness.</P
 236 ></DIV
 237 ><DIV
 238 CLASS="SECT2"
 239 ><H2
 240 CLASS="SECT2"
 241 ><A
 242 NAME="AEN1851"
 243 >4.4.3. Configuration options</A
 244 ></H2
 245 ><P
 246 >&#13;<PRE
 247 CLASS="PROGRAMLISTING"
 248 >type config =
 249     { warner : collect_warnings;
 250       errors_with_line_numbers : bool;
 251       enable_pinstr_nodes : bool;
 252       enable_super_root_node : bool;
 253       enable_comment_nodes : bool;
 254       encoding : rep_encoding;
 255       recognize_standalone_declaration : bool;
 256       store_element_positions : bool;
 257       idref_pass : bool;
 258       validate_by_dfa : bool;
 259       accept_only_deterministic_models : bool;
 260       ...
 261     }</PRE
 262 >
 263
 264 <P
 265 ></P
 266 ><UL
 267 COMPACT="COMPACT"
 268 ><LI
 269 STYLE="list-style-type: disc"
 270 ><P
 271 ><TT
 272 CLASS="LITERAL"
 273 >warner:</TT
 274 >The parser prints
 275 warnings by invoking the method <TT
 276 CLASS="LITERAL"
 277 >warn</TT
 278 > for this warner
 279 object. (Default: all warnings are dropped)</P
 280 ></LI
 281 ><LI
 282 STYLE="list-style-type: disc"
 283 ><P
 284 ><TT
 285 CLASS="LITERAL"
 286 >errors_with_line_numbers:</TT
 287 >If
 288 true, errors contain line numbers; if false, errors contain only byte
 289 positions. The latter mode is faster. (Default: true)</P
 290 ></LI
 291 ><LI
 292 STYLE="list-style-type: disc"
 293 ><P
 294 ><TT
 295 CLASS="LITERAL"
 296 >enable_pinstr_nodes:</TT
 297 >If true,
 298 the parser creates extra nodes for processing instructions. If false,
 299 processing instructions are simply added to the element or document surrounding
 300 the instructions. (Default: false)</P
 301 ></LI
 302 ><LI
 303 STYLE="list-style-type: disc"
 304 ><P
 305 ><TT
 306 CLASS="LITERAL"
 307 >enable_super_root_node:</TT
 308 >If
 309 true, the parser creates an extra node which is the parent of the root of the
 310 document tree. This node is called super root; it is an element with type
 311 <TT
 312 CLASS="LITERAL"
 313 >T_super_root</TT
 314 >. - If there are processing instructions outside
 315 the root element and outside the DTD, they are added to the super root instead
 316 of the document. - If false, the super root node is not created. (Default:
 317 false)</P
 318 ></LI
 319 ><LI
 320 STYLE="list-style-type: disc"
 321 ><P
 322 ><TT
 323 CLASS="LITERAL"
 324 >enable_comment_nodes:</TT
 325 >If true,
 326 the parser creates nodes for comments with type <TT
 327 CLASS="LITERAL"
 328 >T_comment</TT
 329 >;
 330 if false, such nodes are not created. (Default: false)</P
 331 ></LI
 332 ><LI
 333 STYLE="list-style-type: disc"
 334 ><P
 335 ><TT
 336 CLASS="LITERAL"
 337 >encoding:</TT
 338 >Specifies the
 339 internal encoding of the parser. Most strings are then represented according to
 340 this encoding; however there are some exceptions (especially
 341 <TT
 342 CLASS="LITERAL"
 343 >ext_id</TT
 344 > values which are always UTF-8 encoded).
 345 (Default: `Enc_iso88591)</P
 346 ></LI
 347 ><LI
 348 STYLE="list-style-type: disc"
 349 ><P
 350 ><TT
 351 CLASS="LITERAL"
 352 >recognize_standalone_declaration:</TT
 353 > If true and if the parser is
 354 validating, the <TT
 355 CLASS="LITERAL"
 356 >standalone="yes"</TT
 357 > declaration forces that it
 358 is checked whether the document is a standalone document. - If false, or if the
 359 parser is in well-formedness mode, such declarations are ignored.
 360 (Default: true)</P
 361 ></LI
 362 ><LI
 363 STYLE="list-style-type: disc"
 364 ><P
 365 ><TT
 366 CLASS="LITERAL"
 367 >store_element_positions:</TT
 368 > If
 369 true, for every non-data node the source position is stored. If false, the
 370 position information is lost. If available, you can get the positions of nodes
 371 by invoking the <TT
 372 CLASS="LITERAL"
 373 >position</TT
 374 > method.
 375 (Default: true)</P
 376 ></LI
 377 ><LI
 378 STYLE="list-style-type: disc"
 379 ><P
 380 ><TT
 381 CLASS="LITERAL"
 382 >idref_pass:</TT
 383 >If true and if
 384 there is an ID index, the parser checks whether every IDREF or IDREFS attribute
 385 refer to an existing node; this requires that the parser traverses the whole
 386 doument tree. If false, this check is left out. (Default: false)</P
 387 ></LI
 388 ><LI
 389 STYLE="list-style-type: disc"
 390 ><P
 391 ><TT
 392 CLASS="LITERAL"
 393 >validate_by_dfa:</TT
 394 >If true and if
 395 the content model for an element type is deterministic, a deterministic finite
 396 automaton is used to validate whether the element contents match the content
 397 model of the type. If false, or if a DFA is not available, a backtracking
 398 algorithm is used for validation. (Default: true)</P
 399 ></LI
 400 ><LI
 401 STYLE="list-style-type: disc"
 402 ><P
 403 ><TT
 404 CLASS="LITERAL"
 405 >accept_only_deterministic_models:</TT
 406 > If true, only deterministic content
 407 models are accepted; if false, any syntactically correct content models can be
 408 processed. (Default: true)</P
 409 ></LI
 410 ></UL
 411 ></P
 412 ></DIV
 413 ><DIV
 414 CLASS="SECT2"
 415 ><H2
 416 CLASS="SECT2"
 417 ><A
 418 NAME="AEN1895"
 419 >4.4.4. Which configuration should I use?</A
 420 ></H2
 421 ><P
 422 >First, I recommend to vary the default configuration instead of
 423 creating a new configuration record. For instance, to set
 424 <TT
 425 CLASS="LITERAL"
 426 >idref_pass</TT
 427 > to <TT
 428 CLASS="LITERAL"
 429 >true</TT
 430 >, change the default
 431 as in:
 432 <PRE
 433 CLASS="PROGRAMLISTING"
 434 >let config = { default_config with idref_pass = true }</PRE
 435 >
 436 The background is that I can add more options to the record in future versions
 437 of the parser without breaking your programs.</P
 438 ><DIV
 439 CLASS="FORMALPARA"
 440 ><P
 441 ><B
 442 >Do I need extra nodes for processing instructions? </B
 443 >By default, such nodes are not created. This does not mean that the
 444 processing instructions are lost; however, you cannot find out the exact
 445 location where they occur. For example, the following XML text
 446
 447 <PRE
 448 CLASS="PROGRAMLISTING"
 449 >&#60;x&#62;&#60;?pi1?&#62;&#60;y/&#62;&#60;?pi2?&#62;&#60;/x&#62; </PRE
 450 >
 451
 452 will normally create one element node for <TT
 453 CLASS="LITERAL"
 454 >x</TT
 455 > containing
 456 <I
 457 CLASS="EMPHASIS"
 458 >one</I
 459 > subnode for <TT
 460 CLASS="LITERAL"
 461 >y</TT
 462 >. The processing
 463 instructions are attached to <TT
 464 CLASS="LITERAL"
 465 >x</TT
 466 > in a separate hash table; you
 467 can access them using <TT
 468 CLASS="LITERAL"
 469 >x # pinstr "pi1"</TT
 470 > and <TT
 471 CLASS="LITERAL"
 472 >x #
 473 pinstr "pi2"</TT
 474 >, respectively. The information is lost where the
 475 instructions occur within <TT
 476 CLASS="LITERAL"
 477 >x</TT
 478 >.</P
 479 ></DIV
 480 ><P
 481 >If the option <TT
 482 CLASS="LITERAL"
 483 >enable_pinstr_nodes</TT
 484 > is
 485 turned on, the parser creates extra nodes <TT
 486 CLASS="LITERAL"
 487 >pi1</TT
 488 > and
 489 <TT
 490 CLASS="LITERAL"
 491 >pi2</TT
 492 > such that the subnodes of <TT
 493 CLASS="LITERAL"
 494 >x</TT
 495 > are now:
 496
 497 <PRE
 498 CLASS="PROGRAMLISTING"
 499 >x # sub_nodes = [ pi1; y; pi2 ]</PRE
 500 >
 501
 502 The extra nodes contain the processing instructions in the usual way, i.e. you
 503 can access them using <TT
 504 CLASS="LITERAL"
 505 >pi1 # pinstr "pi1"</TT
 506 > and <TT
 507 CLASS="LITERAL"
 508 >pi2 #
 509 pinstr "pi2"</TT
 510 >, respectively.</P
 511 ><P
 512 >Note that you will need an exemplar for the PI nodes (see
 513 <TT
 514 CLASS="LITERAL"
 515 >make_spec_from_alist</TT
 516 >).</P
 517 ><DIV
 518 CLASS="FORMALPARA"
 519 ><P
 520 ><B
 521 >Do I need a super root node? </B
 522 >By default, there is no super root node. The
 523 <TT
 524 CLASS="LITERAL"
 525 >document</TT
 526 > object refers directly to the node representing the
 527 root element of the document, i.e.
 528
 529 <PRE
 530 CLASS="PROGRAMLISTING"
 531 >doc # root = r</PRE
 532 >
 533
 534 if <TT
 535 CLASS="LITERAL"
 536 >r</TT
 537 > is the root node. This is sometimes inconvenient: (1)
 538 Some algorithms become simpler if every node has a parent, even the root
 539 node. (2) Some standards such as XPath call the "root node" the node whose
 540 child represents the root of the document. (3) The super root node can serve
 541 as a container for processing instructions outside the root element. Because of
 542 these reasons, it is possible to create an extra super root node, whose child
 543 is the root node:
 544
 545 <PRE
 546 CLASS="PROGRAMLISTING"
 547 >doc # root = sr         &#38;&#38;
 548 sr # sub_nodes = [ r ]</PRE
 549 >
 550
 551 When extra nodes are also created for processing instructions, these nodes can
 552 be added to the super root node if they occur outside the root element (reason
 553 (3)), and the order reflects the order in the source text.</P
 554 ></DIV
 555 ><P
 556 >Note that you will need an exemplar for the super root node
 557 (see <TT
 558 CLASS="LITERAL"
 559 >make_spec_from_alist</TT
 560 >).</P
 561 ><DIV
 562 CLASS="FORMALPARA"
 563 ><P
 564 ><B
 565 >What is the effect of the UTF-8 encoding? </B
 566 >By default, the parser represents strings (with few
 567 exceptions) as ISO-8859-1 strings. These are well-known, and there are tools
 568 and fonts for this encoding.</P
 569 ></DIV
 570 ><P
 571 >However, internationalization may require that you switch over
 572 to UTF-8 encoding. In most environments, the immediate effect will be that you
 573 cannot read strings with character codes &#62;= 160 any longer; your terminal will
 574 only show funny glyph combinations. It is strongly recommended to install
 575 Unicode fonts (<A
 576 HREF="http://czyborra.com/unifont/"
 577 TARGET="_top"
 578 >GNU Unifont</A
 579 >,
 580 <A
 581 HREF="http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz"
 582 TARGET="_top"
 583 >Markus Kuhn's fonts</A
 584 >) and <A
 585 HREF="http://myweb.clark.net/pub/dickey/xterm/xterm.html"
 586 TARGET="_top"
 587 >terminal emulators
 588 that can handle UTF-8 byte sequences</A
 589 >. Furthermore, a Unicode editor may
 590 be helpful (such as <A
 591 HREF="ftp://metalab.unc.edu/pub/Linux/apps/editors/X/"
 592 TARGET="_top"
 593 >Yudit</A
 594 >). There are
 595 also <A
 596 HREF="http://www.cl.cam.ac.uk/~mgk25/unicode.html"
 597 TARGET="_top"
 598 >FAQ</A
 599 > by
 600 Markus Kuhn.</P
 601 ><P
 602 >By setting <TT
 603 CLASS="LITERAL"
 604 >encoding</TT
 605 > to
 606 <TT
 607 CLASS="LITERAL"
 608 >`Enc_utf8</TT
 609 > all strings originating from the parsed XML
 610 document are represented as UTF-8 strings. This includes not only character
 611 data and attribute values but also element names, attribute names and so on, as
 612 it is possible to use any Unicode letter to form such names.  Strictly
 613 speaking, PXP is only XML-compliant if the UTF-8 mode is used; otherwise it
 614 will have difficulties when validating documents containing
 615 non-ISO-8859-1-names.</P
 616 ><P
 617 >This mode does not have any impact on the external
 618 representation of documents. The character set assumed when reading a document
 619 is set in the XML declaration, and character set when writing a document must
 620 be passed to the <TT
 621 CLASS="LITERAL"
 622 >write</TT
 623 > method.</P
 624 ><DIV
 625 CLASS="FORMALPARA"
 626 ><P
 627 ><B
 628 >How do I check that nodes exist which are referred by IDREF attributes? </B
 629 >First, you must create an index of all occurring ID
 630 attributes:
 631
 632 <PRE
 633 CLASS="PROGRAMLISTING"
 634 >let index = new hash_index</PRE
 635 >
 636
 637 This index must be passed to the parsing function:
 638
 639 <PRE
 640 CLASS="PROGRAMLISTING"
 641 >parse_document_entity
 642   ~id_index:(index :&#62; index)
 643   config source spec</PRE
 644 >
 645
 646 Next, you must turn on the <TT
 647 CLASS="LITERAL"
 648 >idref_pass</TT
 649 > mode:
 650
 651 <PRE
 652 CLASS="PROGRAMLISTING"
 653 >let config = { default_config with idref_pass = true }</PRE
 654 >
 655
 656 Note that now the whole document tree will be traversed, and every node will be
 657 checked for IDREF and IDREFS attributes. If the tree is big, this may take some
 658 time.</P
 659 ></DIV
 660 ><DIV
 661 CLASS="FORMALPARA"
 662 ><P
 663 ><B
 664 >What are deterministic content models? </B
 665 >These type of models can speed up the validation checks;
 666 furthermore they ensure SGML-compatibility. In particular, a content model is
 667 deterministic if the parser can determine the actually used alternative by
 668 inspecting only the current token. For example, this element has
 669 non-deterministic contents:
 670
 671 <PRE
 672 CLASS="PROGRAMLISTING"
 673 >&#60;!ELEMENT x ((u,v) | (u,y+) | v)&#62;</PRE
 674 >
 675
 676 If the first element in <TT
 677 CLASS="LITERAL"
 678 >x</TT
 679 > is <TT
 680 CLASS="LITERAL"
 681 >u</TT
 682 >, the
 683 parser does not know which of the alternatives <TT
 684 CLASS="LITERAL"
 685 >(u,v)</TT
 686 > or
 687 <TT
 688 CLASS="LITERAL"
 689 >(u,y+)</TT
 690 > will work; the parser must also inspect the second
 691 element to be able to distinguish between the alternatives. Because such
 692 look-ahead (or "guessing") is required, this example is
 693 non-deterministic.</P
 694 ></DIV
 695 ><P
 696 >The XML standard demands that content models must be
 697 deterministic. So it is recommended to turn the option
 698 <TT
 699 CLASS="LITERAL"
 700 >accept_only_deterministic_models</TT
 701 > on; however, PXP can also
 702 process non-deterministic models using a backtracking algorithm.</P
 703 ><P
 704 >Deterministic models ensure that validation can be performed in
 705 linear time. In order to get the maximum benefits, PXP also implements a
 706 special validator that profits from deterministic models; this is the
 707 deterministic finite automaton (DFA). This validator is enabled per element
 708 type if the element type has a deterministic model and if the option
 709 <TT
 710 CLASS="LITERAL"
 711 >validate_by_dfa</TT
 712 > is turned on.</P
 713 ><P
 714 >In general, I expect that the DFA method is faster than the
 715 backtracking method; especially in the worst case the DFA takes only linear
 716 time. However, if the content model has only few alternatives and the
 717 alternatives do not nest, the backtracking algorithm may be better.</P
 718 ></DIV
 719 ></DIV
 720 ><DIV
 721 CLASS="NAVFOOTER"
 722 ><HR
 723 ALIGN="LEFT"
 724 WIDTH="100%"><TABLE
 725 WIDTH="100%"
 726 BORDER="0"
 727 CELLPADDING="0"
 728 CELLSPACING="0"
 729 ><TR
 730 ><TD
 731 WIDTH="33%"
 732 ALIGN="left"
 733 VALIGN="top"
 734 ><A
 735 HREF="x1812.html"
 736 >Prev</A
 737 ></TD
 738 ><TD
 739 WIDTH="34%"
 740 ALIGN="center"
 741 VALIGN="top"
 742 ><A
 743 HREF="index.html"
 744 >Home</A
 745 ></TD
 746 ><TD
 747 WIDTH="33%"
 748 ALIGN="right"
 749 VALIGN="top"
 750 ><A
 751 HREF="x1965.html"
 752 >Next</A
 753 ></TD
 754 ></TR
 755 ><TR
 756 ><TD
 757 WIDTH="33%"
 758 ALIGN="left"
 759 VALIGN="top"
 760 >The DTD classes</TD
 761 ><TD
 762 WIDTH="34%"
 763 ALIGN="center"
 764 VALIGN="top"
 765 ><A
 766 HREF="c1567.html"
 767 >Up</A
 768 ></TD
 769 ><TD
 770 WIDTH="33%"
 771 ALIGN="right"
 772 VALIGN="top"
 773 >Updates</TD
 774 ></TR
 775 ></TABLE
 776 ></DIV
 777 ></BODY
 778 ></HTML
 779 >