in reply to Re (tilly) 1: XML::Twig approach/architecture/design question
in thread XML::Twig approach/architecture/design question

XML::Twig provides methods to process this kind of scheme into properly structured XML only because I use it a lot for conversions. When I convert documents from HTML or FrameMaker's MIF into XML I use a 2 step process, first from the original format to some kind of XML (any XML that can easily be created from the document, usually XHTML or something that mirrors the original format), then from that XML to the XML I want using XML::Twig. In that case I often need to add structure to unstructured text.

I also use those methods when I have an already created an XML document and then I realize that it misses additional mark-up, for example adding links from items that have a definition to the definitions.

These are quite specific problems, but I agree that in general it is best to stick to purely XML schemes.

  • Comment on Re: Re (tilly) 1: XML::Twig approach/architecture/design question

Replies are listed 'Best First'.
Re: Re: Re (tilly) 1: XML::Twig approach/architecture/design question
by John M. Dlugosz (Monsignor) on Nov 05, 2001 at 21:49 UTC
    I found that, thanks. It looks like it was designed for exactly what I needed, since it also recurses into subelements!

    Can it (your split member) be directed to filter this recursion, e.g.

    <P>it will find @this and <B>recurse to get @this</B> but should be told <literal>not to scan in @here</literal>.</P>
    But maybe I don't need to... there are other parser issues associated with things like <literal> and I'll bring it up on another thread.

    —John