Comments on: XML, GMarkup, and all that jazz http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/ Thomas Thurman does not like cold meals because of broken applications. Fri, 30 Oct 2009 10:59:14 +0000 http://wordpress.org/?v=2.8.6 hourly 1 By: ᛏᚦ » Blog Archive » When Wednesday was quiet http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/comment-page-1/#comment-7 ᛏᚦ » Blog Archive » When Wednesday was quiet Thu, 14 Feb 2008 14:31:46 +0000 http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/#comment-7 [...] ᛏᚦ Thomas Thurman « XML, GMarkup, and all that jazz [...] [...] ᛏᚦ Thomas Thurman « XML, GMarkup, and all that jazz [...]

]]> By: James Henstridge http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/comment-page-1/#comment-6 James Henstridge Thu, 14 Feb 2008 10:44:10 +0000 http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/#comment-6 I guess the reason the SAX APIs are structured like this is so that they can pass through character data directly from the input buffer without copying (returning spans delimited by tags or entities). In contrast with element start/end tags, the text content can be quite large (unless your XML format does everything through attributes ...) so this makes sense. If you can avoid having to make a copy of every byte of the input, you probably should ... I guess the reason the SAX APIs are structured like this is so that they can pass through character data directly from the input buffer without copying (returning spans delimited by tags or entities).

In contrast with element start/end tags, the text content can be quite large (unless your XML format does everything through attributes …) so this makes sense. If you can avoid having to make a copy of every byte of the input, you probably should …

]]> By: Thomas Thurman http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/comment-page-1/#comment-4 Thomas Thurman Thu, 14 Feb 2008 04:22:36 +0000 http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/#comment-4 @James: That's a very good point. It might be nice if there was a flag you could pass into GMarkup to make it do the buffering for itself, the same way it clearly does for tags it hasn't seen the whole of. @James: That’s a very good point.

It might be nice if there was a flag you could pass into GMarkup to make it do the buffering for itself, the same way it clearly does for tags it hasn’t seen the whole of.

]]> By: James Henstridge http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/comment-page-1/#comment-3 James Henstridge Thu, 14 Feb 2008 04:02:39 +0000 http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/#comment-3 While your parser functions correctly when you feed the entire file, it won't necessarily give the right results if the input is fed to the parser in chunks. If I split the animal name over a chunk boundary, GMarkup may call your text() handler twice, which might lead to output like: I am a li and I go roar. Can you do it? I am a on and I go roar. Can you do it? To handle this case correctly, you'd need to accumulate the text (maybe using GString) when you're inside an interesting element and then print the message from the end_element() handler. While your parser functions correctly when you feed the entire file, it won’t necessarily give the right results if the input is fed to the parser in chunks.

If I split the animal name over a chunk boundary, GMarkup may call your text() handler twice, which might lead to output like:

I am a li and I go roar. Can you do it?
I am a on and I go roar. Can you do it?

To handle this case correctly, you’d need to accumulate the text (maybe using GString) when you’re inside an interesting element and then print the message from the end_element() handler.

]]>