From: Ian S. <ian...@st...> - 2006-01-09 15:54:10
|
Matt Leotta wrote: > Gamze, > > I am also in favor of moving XML IO capabilities into core. While > moving your basic XML element class into vsl is better than having it > in contrib, I'm wondering if there should be really be a new library > for this. The vsl library is designed for binary IO, and maybe this > should be independent from XML IO. What about a new vxml library in > core? Does anyone else support this idea? While it is just output - there is barely enough code to bother adding a brand new library. However, if you do plan to have input - then vxml would make a lot of sense. > Of course, I think it's critical that we also have an XML parser at > some point. Should VXL have it's own primitive XML parser or should > it depend on some third party library like Expat? If it does depend > on a third party library should that library go into v3p or do we > require that the user install it separately? A simple parser entirely held within vxml would be nice. I suspect that writing an xml parser is not straight-forward, in which case using an external library would be sensible. The general rule we seem to use is that any libraries needed by vxl/core should be provided in vxl/v3p. > I think XML would be useful for storing stream parameters in the new > video library that is currently under development. So, I am willing > to help with this effort if needed. XML is useful for application to application interoperability, for files that occasionally might be inspected or modified by humans. It would be useful to store and load big complicated VXL objects to XML, as a somewhat more penetrable version of vsl's binary format. <XML rant> However, I convinced that XML is a completely unsuitable format for files that are regularly edited by humans. XSLT (a programming language written in XML for manipulating XML) sounds like a nice idea before you have to use it. I hated it, even with an XML aware editor. Moving stuff around never worked, and when I needed to edit some source on a different platform, using vi over ssh - I could have murdered the original designers of DART for having chosen XSLT. For files that humans regularly hand-edit (source code, config files, etc) a much simpler format is preferable. The simple property file is ideal if your data is non-hierarchical. Indeed my group here at Manchester use a few simple parsing functions (mbl_parse_block and mbl_read_props) to read a hierarchical version of the property file format for most of our configuration needs. If you want a standard format, then YaML (http://www.yaml.org/) has a lot to recommend it. Don't use XML just because everybody else (i.e. the JAVA community) uses it. Everybody else is wrong! </XML rant> Ian. |