Re: Xpath

--===============0860227996==
Content-Type: multipart/alternative; boundary=f46d0444ef43c8ce8f04d07fa1ea

--f46d0444ef43c8ce8f04d07fa1ea
Content-Type: text/plain; charset=ISO-8859-1

If you have a large document and need high performance, say if you need to
do this transform on a huge file on a repetitive basis, then you may want
to delve into SAX. Otherwise XSLT is probably the most straightforward
solution, IF you know XSLT (or if you're going to learn it anyway there's
no time like the present). Its a useful language to know. You could use DOM
+ XPath but it rapidly gets to be irritatingly verbose. SAX can be tricky
as well if you have a lot of state you need to keep, such as if output is
related in a complex way to input. SAX is great when the output and input
relate in a fairly simple way, but if the correspondence is less
straightforward it can be a real PITA to build the right state machine
because SAX only gives you a "keyhole" into the incoming document. With
XSLT it is pretty easy to consider data from completely different parts of
the document when generating output. XSLT is of course rather a pig. It
doesn't HAVE to maintain the whole DOM tree in memory, but optimizing it is
not always terribly obvious or even possible.

On Sun, Dec 9, 2012 at 11:39 PM, Francisco Obispo <[email protected]> wrote:

>
> On Dec 9, 2012, at 8:14 PM, Stephen Wilcoxon <[email protected]> wrote:
>
> > XML::LibXML::SAX seems to be fairly poorly documented (but that's true
> of all of XML::LibXML).
> >
>
>
> I have not had problems with XML::LibXML's documentation.
>
>
> > I would discourage the use of a DOM parser as it reads everything into
> memory so suffers performance issues as documents get larger (and can run
> out of memory).  If I'm going to read everything into memory, I just use
> XML::Simple.
> >
>
> It all depends on the use you have, if its large documents, I would
> encourage a SAX-based parser, XML::Parser::ExpatXS, which is really fast.
> If its small documents, The DOM interface will work just fine, specially
> when you need to perform validation (DTD, Schema, RelaxNG, etc.).
>
> With the DOM doc in memory you can perform XPath searches, which is fast,
> again for small docs.
>
> You might also want to take a look at XML::Rabbit, which uses Moose and
> allows you to build Perl objects from XML docs.
>
> Any of these approaches will work for you, you would have to share some of
> your requirements for me to give you more guidance.. is it performance?
> code readability/maintainability ? system constraints?
>
>
>
>
> Francisco Obispo
> Director of Applications and Services - ISC
> email: [email protected]
> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
> PGP KeyID = B38DB1BE
>
> _______________________________________________
> Perl-XML mailing list
> [email protected]
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>



-- 
The Wise adapts himself to the world. The Fool adapts the world to himself.
Therefore, all progress depends on the Fool.

--f46d0444ef43c8ce8f04d07fa1ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If you have a large document and need high performance, say if you need to =
do this transform on a huge file on a repetitive basis, then you may want t=
o delve into SAX. Otherwise XSLT is probably the most straightforward solut=
ion, IF you know XSLT (or if you&#39;re going to learn it anyway there&#39;=
s no time like the present). Its a useful language to know. You could use D=
OM + XPath but it rapidly gets to be irritatingly verbose. SAX can be trick=
y as well if you have a lot of state you need to keep, such as if output is=
 related in a complex way to input. SAX is great when the output and input =
relate in a fairly simple way, but if the correspondence is less straightfo=
rward it can be a real PITA to build the right state machine because SAX on=
ly gives you a &quot;keyhole&quot; into the incoming document. With XSLT it=
 is pretty easy to consider data from completely different parts of the doc=
ument when generating output. XSLT is of course rather a pig. It doesn&#39;=
t HAVE to maintain the whole DOM tree in memory, but optimizing it is not a=
lways terribly obvious or even possible. <br>
<br><div class=3D"gmail_quote">On Sun, Dec 9, 2012 at 11:39 PM, Francisco O=
bispo <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_b=
lank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div class=3D"im"><br>
On Dec 9, 2012, at 8:14 PM, Stephen Wilcoxon &lt;<a href=3D"mailto:wilcoxon=
@gmail.com">[email protected]</a>&gt; wrote:<br>
<br>
&gt; XML::LibXML::SAX seems to be fairly poorly documented (but that&#39;s =
true of all of XML::LibXML).<br>
&gt;<br>
<br>
<br>
</div>I have not had problems with XML::LibXML&#39;s documentation.<br>
<div class=3D"im"><br>
<br>
&gt; I would discourage the use of a DOM parser as it reads everything into=
 memory so suffers performance issues as documents get larger (and can run =
out of memory). =A0If I&#39;m going to read everything into memory, I just =
use XML::Simple.<br>

&gt;<br>
<br>
</div>It all depends on the use you have, if its large documents, I would e=
ncourage a SAX-based parser, XML::Parser::ExpatXS, which is really fast. If=
 its small documents, The DOM interface will work just fine, specially when=
 you need to perform validation (DTD, Schema, RelaxNG, etc.).<br>

<br>
With the DOM doc in memory you can perform XPath searches, which is fast, a=
gain for small docs.<br>
<br>
You might also want to take a look at XML::Rabbit, which uses Moose and all=
ows you to build Perl objects from XML docs.<br>
<br>
Any of these approaches will work for you, you would have to share some of =
your requirements for me to give you more guidance.. is it performance? cod=
e readability/maintainability ? system constraints?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
Francisco Obispo<br>
Director of Applications and Services - ISC<br>
email: <a href=3D"mailto:[email protected]">[email protected]</a><br>
Phone: <a href=3D"tel:%2B1%20650%20423%201374" value=3D"+16504231374">+1 65=
0 423 1374</a> || INOC-DBA *3557* NOC<br>
PGP KeyID =3D B38DB1BE<br>
<br>
_______________________________________________<br>
Perl-XML mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]=
veState.com</a><br>
To unsubscribe: <a href=3D"http://listserv.ActiveState.com/mailman/mysubs" =
target=3D"_blank">http://listserv.ActiveState.com/mailman/mysubs</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>The Wise ad=
apts himself to the world. The Fool adapts the world to himself. Therefore,=
 all progress depends on the Fool.<br>

--f46d0444ef43c8ce8f04d07fa1ea--

--===============0860227996==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

--===============0860227996==--