Ignoring your attempts at using an XML parser as an XML generator, one is left with:

# XML::Smart
print $sXML->{book}[3]{title};

# XML::LibXML
print $root->find('book[4]/title');
[download]

# XML::Smart
my @books = $sXML->{book}('@');

# XML::LibXML
my @books = $root->findnodes('book');
[download]

So XML::LibXML is a little bit wordier, but there's a good reason for that. XML::Smart chose to sacrifice some critical functionality to offer its interface.

• XML::LibXML supports namespaces. XML::Smart doesn't (except when used to generate documents).

• XML::LibXML preserves the order of the children of elements. XML::Smart can't even list the children of an element.

• Comments are dropped.

• Only can only distinguish distinguish between elements and attributes when using XML::LibXML.

Either of the first three would make XML::Smart incapable of dealing with the most commonly used XML format (XHTML). The second means it's incapable of handling just about every XML format out there.

Update: Simplified an XML::Smart example that wasn't optimal.
Update: Added third and fourth bullet.

Ignoring your attempts at using an XML parser as an XML generator

Who said LibXML is just a parser?

XML::LibXML supports namespaces. XML::Smart doesn't (except when used to generate documents).

Yes, probably because it's too old for it. It doesn't support XSD, either, which is part of the reason I'm switching to LibXML.

I'm not debating that Smart is missing critical functionality. I'm frustrated that LibXML is this mature, and is a Perl module, and yet is this clunky at navigation. Nor are there any modules for XML::LibXML that enhance it to fix its navigation.

I mean seriously, this is what I have to do to check for a tag and fill data for it:

# Before
$sn->{'SourceDBType'} ||= 'XML';

# After
$sn->findvalue('SourceDBType') || ($sn->find('SourceDBType') ? $sn->fi
+nd('SourceDBType')->setData('XML') : $sn->addNewChild(undef, 'SourceD
+BType')->setData('XML'));
[download]

Are you kidding me?!?!  That's a horrible mess!  And god forbid I do something like $sn->find('SourceDBType')->setData('XML') without checking the existence of SourceDBType first.  That'll give me a fatal error.

XML::LibXML preserves the order of the children of elements. XML::Smart can't even list the children of an element.

Incorrect. Smart does both: $XML->{server}{address}[1]('@');  # there's your children of that <address> tag

Who said LibXML is just a parser?

You, for one.

Yes, probably because it's too old for it.

I meant it can't support namespaces.

I'm not debating that Smart is missing critical functionality.

Neither was I. I was referring to what its design allows.

Are you kidding me?!?! That's a horrible mess!

Are you kidding me? The equivalent would be

$sb->setAttribute(SourceDBType => 'XML') if !$sb->setAttribute('XML');
[download]

Incorrect. Smart does both:

Sorry, but that's not working.

use strict;
use warnings;
use feature qw( say );

use XML::Smart qw( );

my $doc = XML::Smart->new(<<'__EOI__');
<root>
   <node>
     a
     <foo/>
     b
     <bar/>
     c
  </node>
</root>
__EOI__

my @children = $doc->{root}{node}[0]('@');
say @children == 5 ? "ok" : "XXX";
[download]

1
XXX
[download]

What I found was absolutely appalling, especially compared to XML::Smart

Yes, gmpassos is M.I.A., this means you can take over maintenance/development of XML::Smart -- you can also fork the codebase at any time

Plus, the documentation for XML::LibXML is horrid!

Actually, no, it really isn't. It is quite comprehensive and complete; in any case, as they say, patches welcome

(For god's sake, jQuery was created because people were sick of typing "document.getElementById" all the damn time.)

Actually, no it wasn't. jQuery was created because html/browsers did not expose xpath to javascript. XML::LibXML gives you xpath.

Any idiot can define a one char shortcut for document.getElementById

Where is XML::LibXML::Smart || XML::LibXML::Tree || XML::LibXML::jQuery?

Eh?

• Perl-XML Frequently Asked Questions
• XML::XSH2 - A powerfull scripting language/shell for XPath-based editing of XML
• jQuery in Perl
• XML::Compile
• site:http://www.xml.com/ perl
• ...

Yes, gmpassos is M.I.A., this means you can take over maintenance/development of XML::Smart -- you can also fork the codebase at any time.

That's not my point, and something I don't have the time for right now. XML::Smart is mostly dead and XML::LibXML is now the currently maintained XML module. My point is that with all of the development and talk about how great this module is, why hasn't there been some efforts to make it more elegant and "sugary"?

Actually, no, it really isn't. It is quite comprehensive and complete; in any case, as they say, patches welcome

A typical RTFM-like response, hmm?

And again, the docs are spread all over creation. Quick, tell me how to create a XML tree of nodes. Well, that's going to diving into 4-5 different module docs to look up the appendChild, setText, etc. methods. Not to mention that there are about 10 different ways to create these things and there is no tutorial saying "Okay, this is the RIGHT way to do it that uses the least code."

For that manner, can anybody tell me how XML::LibXML::SAX works? Because the documentation there doesn't give me any methods to use. Even the other sections, like this one, literally say "Usage is as above", which means "I'm too lazy to actually list out the methods for this module." Meanwhile, XML::LibXML::SAX::Parser, the class that isn't "DEPRACED" has absolutely no documentation.

Actually, no it wasn't. jQuery was created because html/browsers did not expose xpath to javascript. XML::LibXML gives you xpath.

And did they implement XPath? No. They used the CSS selector language to grab nodes. Why? Because everybody was familiar with it and we don't need Yet Another Selector Language. Just stick with one and be done with it.

Any idiot can define a one char shortcut for document.getElementById

Yes, and when millions of "idiots" are defining one-char shortcuts for a function, there is something wrong with the function.

Eh?

Okay, that's just a list of random modules.

That's not my point, and something I don't have the time for right now. XML::Smart is mostly dead and XML::LibXML is now the currently maintained XML module.

If its not your point, why dwell on it? If you find it useful and convenient, why not keep it updated? Software only dies if you stop using it.

My point is that with all of the development and talk about how great this module is, why hasn't there been some efforts to make it more elegant and "sugary"?

Hmm, why does an interface to a standards based library not come with sugar?

Perhaps, because diabetes is an epidemic? I don't know -- seems like too much work for one man

A typical RTFM-like response, hmm?

Is it? I found it quite civil in comparison to your post. I feel the same as Re: XML::LibXML - WHAR HASH TREES WHAR?!

And again, the docs are spread all over creation.

Why is that a problem? Perl documentation doesn't come all on one page either -- you could always make one page with all the docs :)

Quick, tell me how to create a XML tree of nodes. Well, that's going to diving into 4-5 different module docs to look up the appendChild, setText, etc. methods.

http://cpansearch.perl.org/src/SHLOMIF/XML-LibXML-1.80/t/04node.t

Not to mention that there are about 10 different ways to create these things and there is no tutorial saying "Okay, this is the RIGHT way to do it that uses the least code."

Interfacing to libxml is a big enough job -- the docs aren't there to teach you programming, oo concepts, patterns, paradigms (like event-based programming ), xml ...

For that manner, can anybody tell me how XML::LibXML::SAX works? Because the documentation there doesn't give me any methods to use. Even the other sections, like this one, literally say "Usage is as above", which means "I'm too lazy to actually list out the methods for this module." Meanwhile, XML::LibXML::SAX::Parser, the class that isn't "DEPRACED" has absolutely no documentation.

The docs say

XML::LibXML provides an interface to libxml2 direct SAX interface

The SAX interface of XML::LibXML is based on the famous XML::SAX interface. It uses the generic interface as provided by XML::SAX::Base.

So XML::SAX, XML::SAX::Base, http://cpansearch.perl.org/src/SHLOMIF/XML-LibXML-1.80/t/14sax.t, SAX is the Simple API for XML, SAX

Yes, and when millions of "idiots" are defining one-char shortcuts for a function, there is something wrong with the function.

No there isn't. You still use print don't you? or say? You're not using p or s are you? Or in javascript terms, you're still using $('a[href]').each( aren't you? You're not using $('a[href]').e(?

And did they implement XPath? No. They used the CSS selector language to grab nodes.

$('a[href$="pdf"]') -- looks like xpath to me -- sure, its called "css2", but its xpath -- in anycase, xpath is the standard for xml

Okay, why did nobody mention XML::Compile? (Well, besides stuffing it in a list above.) It uses XML::LibXML directly. It's a mature and well-supported set of modules. It creates hash trees, and it uses those to create XML from schema files.

Why isn't, like, 100% of the Perl community using this?

DOM may be terrible in some ways, but it's not LibXML's fault for following it. People expect that nearly any widely used language out there will have a DOM parser. That way, we can all suffer equally.

I suspect what you want is XML::Simple.

All I want is the most powerful and best XML parser available. XML::LibXML is fast, linked to a very common lib, and regularly updated. However, it's bedside manner has something to be desired. XML::Simple has been regarded as the easier of the two, but not the best.

Why does both have to suck in opposite but equal manners? What's wrong with having both the power of the methods and tying it to a hash tree? You can put a hash tree on top of the methods. What's wrong with something like this?

$pXML->{bookstore}{book}[3]->appendText(", The");
my @books = $pXML->('//book');
$node->('/bookstore/book[price>35]/price')->setData(24.95);
[download]

XML::Simple has been regarded as the easier of the two.

XML::Simple is the hardest XML parser to use.

$smart->{book}('@')
[download]

is

ref($simple->{book}) && ref($simple->{book}) eq 'ARRAY'
   ? $simple->{book}
   : [ $simple->{book} ]
[download]

or

ForceArray => [qw( book )]  # In constructor
$simple->{book}
[download]

XML::Smart appears to be an attempt to fix this problem of XML::Simple. (It still suffers from other problems of XML::Simple.)

LibXML is doing things that way for perfectly defensible reasons. It's a thin wrapper around a C library.

If you'd like to simplify things on top of that, then by all means, start a project to fix it. Complaining about it on in SoPW, though, is unproductive.

---

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

If you just want to vent steam, use the Chatterbox or IRC.