Re: [ANNOUNCEMENT] VTD-XML releases under GPL

From: Ron <support_at_dbainfopower.com>
Date: Mon, 28 Jun 2004 15:50:59 -0700
Message-ID: <vvudneQU_JdOPX3d4p2dnA_at_comcast.com>


Hello Jimmy,

  While your tool may be a good one - I think it is a waste of bandwidth to post this announce in oracle database group.

  You would get much more attention and feedback in groups where XML developers post.

Thanks,

   Ron
   Support
   DBA Infopower LLC
   http://www.dba-ip.com

"Jimmy zhang" <jzhang_at_ximpleware.com> wrote in message news:NqZDc.124794$HG.56550_at_attbi_s53...
> I am pleased to announce that version 0.5 of VTD-XML -- a new,
> non-extractive, Java-base XML processing API licensed under GPL
> -- is now freely available on sourceforge.net. For source code,
> documentation, detailed description of API and code examples,
> please visit
>
> http://vtd-xml.sf.net
>
> Capable of random-access, VTD-XML attempts to be both memory
> efficient and high performance. The starting point of this project is
> the observation that, for XML documents that don't declare entities
> in DTD, tokenization can indeed be done by only recording the starting
> offset and length of a token. A discussion on this subject appeared
> in a recently article on xml.com
> (http://www.xml.com/pub/a/2004/05/19/parsing.html).
>
> The core technology of VTD-XML is a binary format specification
> called Virtual Token Descriptor (VTD). A VTD record is a 64-bit integer
> that encodes the starting offset, length, type and nesting depth of a
> token in an XML document. Because VTD records don't contain actually
> token content, they work alongside of the original XML document, which
> is maintained intact in memory by the processing model.
>
> VTD's memory-conserving features can be summarized as follows:
>
> * Avoid Per-object overhead -- In many VM-based object-oriented
> programming languages, per-object allocation incurs a small amount
> of memory overhead. A VTD record is immune to the overhead because
> it is not an object.
> * Bulk-allocation of storage -- Fixed in length, VTD records can be
> stored in large memory blocks, which are more efficient to allocate
> and GC. By allocating a large array for 4096 VTD records, one incurs
> the per-array overhead (16 bytes in JDK 1.4) only once across 4096
> records, thus reducing per-record overhead to very little.
>
> Our benchmark indicates that VTD-XML processes XML at the performance
> level similar to (and often better than) SAX with NULL content handler.
> The memory usage is typically between 1.3x ~ 1.6x of the size of the
> document, with "1" being the document itself.
>
> Other features included in this release are:
>
> * Incremental update -- VTD-XML allows one to modify content of XML
> without touching irrelevant parts of the document.
> * Content extraction -- VTD-XML also allows one to pull an element
> out of XML in its serialized format. This can be an important
> feature for partial signing/encryption of SOAP payload for
> WS-security.
>
> In the upcoming releases, we plan to add the persistence support so
> that one can save/load VTD to/from the disk along with the XML documents
> to avoid repetitive parsing in read-only situations. XPATH support is
> also on the development roadmap. However, we would like to collect as
> many suggestions and bug reports before taking the next step.
>
> Your input and suggestions are very important to make VTD-XML a truly
> useful XML processor.
>
> Thanks,
>
> Jimmy Zhang
>
>
Received on Tue Jun 29 2004 - 00:50:59 CEST

Original text of this message