Re: [xml] lazy libxml

On Tue, Jun 20, 2006 at 09:51:00AM +0100, Nic James Ferrier wrote:
XRT has to handle all types of content though, not just XML. I would
like XRT to be able to handle binary types (like raster images) by
representing them as XML binary objects (as Tim Bray has suggested)

  <element xml:binary="base64">

  If I remember that blog from last year it wqas really intended only
for minimal size blob, like an icon or a thumbnail. Oh and using the
xml namespace for something not coming from a W3C recommendation is a
very risky business.

Consider this example of imagined XRT:

   <xsl:variable name="pngfile"  select="lazy.get('adabyron.png')"/>
   <xsl:variable name="jpgfile" select="lazy.convert($pngfile, 'jpg')"/>

The idea here is that there is a lazy object representing the
pngfile which is then converted to another lazy object which
represents a jpg file.

  Embedding the full image in the XML does not make sense to me:

    - it's inefficient in bandwidth (HTTP can transport binary fine)
    - it defeats all potential caching in HTTP from server to client

 Technologically this sounds wrong to me from an content service over HTTP
perspective, but my opinion is only that.

Only when I do:

   <xsl:value-of select="$jpgfile"/>

does the actual import of the png file and it's conversion to jpg
actually happen.

  And since all the generation there is really driven by low level 
libxml2 C code that's where the conversion woult had to be done.

You can always add up a function in the _private field
of a node, but that will only be interpreted by non-libxml2 code by

That's right. This would seem to be some scary fundamental change.

What I would have to do is replace all the code which currently
handles the content of a node and make it check to see whether the
node is delayed/lazy or not and if lazy, compute it.

  and this scattered all over the place, in libxml2 tree, XPath, and in
libxslt. I really don't see how to extend libxml2 model to put this in without
changes all other the code, a very risky business.

FWIW SXML already has an understanding of lazy XML I believe:

  first time I heard of SXML. Well they use high level language to 
process the content, adding this kind of extensions may be easier for them.


Daniel Veillard      | Red Hat
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]