EnlightenedPerlOrganisation / task-kensho

A Glimpse at an Enlightned Perl Distribution
http://search.cpan.org/dist/Task-Kensho
Other
71 stars 23 forks source link

Data::Edit::Xml #49

Open philiprbrenan opened 5 years ago

philiprbrenan commented 5 years ago

Please consider adding: https://metacpan.org/pod/Data::Edit::Xml to: https://metacpan.org/pod/Task::Kensho under: Task::Kensho::XML: XML Development ?

perigrin commented 5 years ago

I'd not heard of this module. Looking at it's POD it's using non-standard ways of creating objects (my $a = Data::Edit::Xml::new q(<a><b><c/></b><d><c/></d></a>);) and that makes me nervous.

Can you explain a bit more about why you consider it a best of breed module? (This is probably something you could put in the POD too to explain why someone should use your module over XML::SAX, XML::Smart, XML::Simple, XML::Twig or any of the other XML modules out there.)

philiprbrenan commented 5 years ago

Hi Chris:

Thank you for your note.

I use Data::Edit::Xml (Dex) to do large scale conversions of Xml documents, for instance from DocBook to Dita. During such conversions the same basic transformations come up over and over again, as in say unwrap under

as there is no point in bolding a link. Each of the 500+methods supplied in Dex has a notion of context which enables me to write very compact code to achieve such an effect as in: *$node->unwrap_b_xref* which means only unwrap the indicated node if it has a *b* tag and is under a node with an *xref* tag. You are probably familiar with Scintilla which supplies lots of common methods for use in text editors. Dex behaves in a similar way for XML. There are lots of basic transforms that are highly reusable - it would be a waste of time to recode and test these for every project when the reoccur so frequently. Dex uses https://metacpan.org/pod/XML::Parser to do the actual parsing of input strings and files. XML::Parser in turn (I believe) relies on libxml as do the other modules you mention. So the underlying technology is identical - it is the superstructure that is different. CPAN is a powerful tool as it reduces the need to reinvent the wheel. There are a surprising number of ways that even a small number of XML elements can be transformed. Dex serves as a catalog of such transformations within CPAN and thus frees programmers from the repetitive task of reinventing, recoding, retesting, redocumenting them. At one level this is just an interesting academic exercise as not every transformation so cataloged sees a lot of use. But a surprising number of transformations do see very intensive use. For example: *mergeLikePrev* which concatenates the children of two parent nodes under the first parent node if the two parent nodes have the same tag does not strike one on first encounter as a particularly useful method. Yet it is invaluable in converting Word Documents to Dita as these documents tend to be full of broken lists which *mergeLikePrev* can repair. Before launching into this arcane area I did indeed try to write such transformations using the modules you have indicated. My experience was that while it could be done it was taking me too long and I was repeating myself too often for the process to be performed profitably. Dex grew out of my efforts to stop repeating myself by reusing code more effectively. As you can see, I could elaborate on this subject for some time. Please let me know if I should continue to do so? On Fri, Sep 13, 2019 at 4:48 PM Chris Prather wrote: > I'd not heard of this module. Looking at it's POD it's using non-standard > ways of creating objects (my $a = Data::Edit::Xml::new > q();) and that makes me nervous. > > Can you explain a bit more about why you consider it a best of breed > module? (This is probably something you could put in the POD too to explain > why someone should use your module over XML::SAX, XML::Smart, XML::Simple, > XML::Twig or any of the other XML modules out there.) > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . > -- Thanks, Phil Philip R Brenan