On Mon, Feb 28, 2011 at 5:43 PM, Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > On Mon, Feb 28, 2011 at 10:20:16AM -0300, Gustavo Sverzut Barbieri wrote: >> I've worked with expat before and it's way more complex to use and >> heavy. Sure, it will work and will handle namespace, and encoding... >> but many times you don't want or need it. > > The point is that if you don't do that, you no longer have an XML > parser. So don't even call it that. If you explicitly want to use only a > subset, going with JSON tends to be a much simpler option...
>> the current SAX-like api I'm calling is 1 single function that >> receives a buffer and a callback, calls you back with pointers to the >> buffer you handled it. It does not consider any form of encoding, thus >> it will never break, it's up to you. It will fallback nicely on >> unhandled conditions, like entity definitions are not handled, they >> are given to you as an open tag statement. That is because MOST of >> these files are ascii and do not use these xml nasty features such as >> entities & like. > > That doesn't work either. XML can't be parsed encoding neutral. Consider > documents in shift_jis for this. If you implement a fallback path to > handle all well formed XML documents using a full blown parser, you > haven't saved anything in terms of code complexity and the request for a > benchmark made in this thread is completely valid to justify the > *additional* complexity. > >> Even the escaping ({ or &) is not handled, at least with efl >> you're likely to not need it anyway as Evas already handles it for >> you. > > This sounds like moving complexity to the wrong layer, too. Ignoring the > question of whether a document editor should preserve entities or not, > most of the users of a "simple" parser should see entities at all or > have to deal with them. There is a good reason for wanting to use them > by human editors. > > In short: if it doesn't implement XML, it is not an XML parser. Most of > the configuration files sadly using XML are exactly that. Providing a > simplified interface is fine, it doesn't require throwing compatibility > over board. If you don't want XML, consider something like Apple's > proplib or just JSON. Don't retrofit it into existing file formats. We do need a XML parser for FreeDesktop files. They have a really limited complexity and we can't change them. As for configuration file, we do have eet, that does the job pretty well for us. -- Cedric BAIL ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
