Re: Re: Re: XML::Twig - literal nodes

Sorry, you can't do this in XML.

XML::Twig reads XML files, and a file with random &'s and <'s is _not_ XML. Hence XML::Twig or any XML tool can't do a thing for you there. If you want to include random special characters then you _have_ to use one of the 2 appropriate schemes allowed in XML: either escape each instance of those character or use a CDATA section.

What you are describing is an interesting format, it is an extension of the input format accepted by PerlMonks actually, but it is not XML. And no tool based on an XML parser can accept it.

Darn! You've reached the limit beyond which I can't extend XML::Twig. I can't believe it!

Comment on Re: Re: Re: XML::Twig - literal nodes

Replies are listed 'Best First'.
Re: Re: Re: Re: XML::Twig - literal nodes by John M. Dlugosz (Monsignor) on Nov 09, 2001 at 00:18 UTC
Picture this: The primitive parser (Expat in your case) reads, conceptually, a character at a time and runs it through the grammar rules. When I get the open-tag event, the code can change a bit in the thing that the parser is reading from, so that filtering is turned on. It turns itself off when it sees the end tag. So, it requires knowledge of the exact input position of the parser, so that logically it reads one char at a time (if it buffers lines, it needs to flush & resync to the "logical" position). So I think XML::Twig could handle it, using that method: input filters that are specified as processing input exactly up to the tag that triggered the current callback. So, if the callback changes something in the filter, it will affect everything following that tag in the source. See what I mean? —John	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: XML::Twig - literal nodes
by John M. Dlugosz (Monsignor) on Nov 09, 2001 at 00:18 UTC

The primitive parser (Expat in your case) reads, conceptually, a character at a time and runs it through the grammar rules.

When I get the open-tag event, the code can change a bit in the thing that the parser is reading from, so that filtering is turned on. It turns itself off when it sees the end tag.

So, it requires knowledge of the exact input position of the parser, so that logically it reads one char at a time (if it buffers lines, it needs to flush & resync to the "logical" position).

So I think XML::Twig could handle it, using that method: input filters that are specified as processing input exactly up to the tag that triggered the current callback. So, if the callback changes something in the filter, it will affect everything following that tag in the source.

See what I mean?

—John

[reply]