From: Ian S. <ian...@st...> - 2006-01-09 09:31:22
|
vxl-maintainers is the appropriate location for this discussion. Gamze Tunali wrote: > Hi, > > We needed to write the content of some basic vxl > objects to the output stream as XML elements as part > of our recent project. I added vgl/xio and vnl/xio > directories for that purpose two days ago. Like > vgl_io, vgl_xio is responsible from writing the class > attributes to the io streams (same as vnl_xio). > > I used a basic XML element class from bxml to seperate > the formatting decision, but if we strictly against > depending on another package in vgl and vnl, I can > basically write to the stream directly in vgl_xio and > vnl_xio. Since vsl is used for vgl_io and vnl_io, > maybe we can create a basic XML element class there > instead. I think it would be wise to add a basic XML element class to vsl. I seem to remember that bad things happen if you don't maintain an acyclic dependency graph between the modules (as well as between the libraries.) At the very least, when CMake'ing for the first time, the vnl/xio direction will be trying to reference a library (bxml) that CMake hasn't come across yet. > I just wanted to inform the vxl users of this addition > and get some suggestions if the additions are > violating the well-thought design rules. The code seems fairly straight-forward. I have one question though - Do you have any plans for XML reading functions? Is getting an xml parser into vxl too difficult? Ian. |
From: Matt L. <mat...@gm...> - 2006-01-09 15:08:32
|
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? 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? 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. Matt Leotta On 1/9/06, Ian Scott <ian...@st...> wrote: > vxl-maintainers is the appropriate location for this discussion. > > > Gamze Tunali wrote: > > Hi, > > > > We needed to write the content of some basic vxl > > objects to the output stream as XML elements as part > > of our recent project. I added vgl/xio and vnl/xio > > directories for that purpose two days ago. Like > > vgl_io, vgl_xio is responsible from writing the class > > attributes to the io streams (same as vnl_xio). > > > > I used a basic XML element class from bxml to seperate > > the formatting decision, but if we strictly against > > depending on another package in vgl and vnl, I can > > basically write to the stream directly in vgl_xio and > > vnl_xio. Since vsl is used for vgl_io and vnl_io, > > maybe we can create a basic XML element class there > > instead. > > I think it would be wise to add a basic XML element class to vsl. I seem > to remember that bad things happen if you don't maintain an acyclic > dependency graph between the modules (as well as between the libraries.) > At the very least, when CMake'ing for the first time, the vnl/xio > direction will be trying to reference a library (bxml) that CMake hasn't > come across yet. > > > I just wanted to inform the vxl users of this addition > > and get some suggestions if the additions are > > violating the well-thought design rules. > > The code seems fairly straight-forward. I have one question though - Do > you have any plans for XML reading functions? Is getting an xml parser > into vxl too difficult? > > Ian. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
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. |
From: Amitha P. <pe...@cs...> - 2006-01-09 16:27:45
|
On the topic of XML for serialization: Without a DTD, an XML format is not different from any other markup. I like Ian's idea of YAML, though I only made a cursory glance at it. One advantage of XML is that, due to current popularity, many more people and tools are aware of the XML syntax. However, I agree with Ian that the XML syntax is quite verbose and painful for manual editing. I think Matt's idea of a vxml is useful for input. I don't think you need a separate library to output XML: XML is very, very easy to output. vsl is the v-serialization-library. I think it should do both types of serializations. In particular, I think vsl should simply provide, additionally, vsl_x_read and vsl_x_write routines corresponding to the current vsl_b_read and vsl_b_write routines. Then, v*l_io would provide both binary and other serialization options. I think adding more libraries (*_xio) is unnecessary in this situation. Clearly, expanding the interface as described above does not degrade performance. And, the I would do it, it doesn't add any more dependencies. I'd be hesistant to put a dependency on an external library, such as Expat, simply to output XML. However, XML is notoriously difficult to parse, and using another implementation to do the work is a good idea. I'm not sure, though, what you'd gain from a vxml as opposed to directly depending on, say, v3p/expat. Amitha. |
From: Amitha P. <pe...@cs...> - 2006-01-09 16:37:46
|
Just after I wrote the previous message, it occured to me that I was writing about XML output, but not realizing that a output-only serialization library is often useless. Thus, XML output implies XML input, which most likely implies a dependency on an external library. In this case, I'm not sure if including both everything in vsl is a good idea or not. But I'd be in favour of it, provided it failed gracefully when the dependency was not met. For example, without Expat, vsl can do everything except XML input. Depending on the complexity of Expat, this may be another argument for using a simpler thing like YAML. (Assuming YAML is a simpler thing.) Amitha. |
From: William A. H. <bil...@ny...> - 2006-01-09 16:42:31
|
At 11:37 AM 1/9/2006, Amitha Perera wrote: >Just after I wrote the previous message, it occured to me that I was >writing about XML output, but not realizing that a output-only >serialization library is often useless. Thus, XML output implies XML >input, which most likely implies a dependency on an external library. > >In this case, I'm not sure if including both everything in vsl is a >good idea or not. But I'd be in favour of it, provided it failed >gracefully when the dependency was not met. For example, without >Expat, vsl can do everything except XML input. > >Depending on the complexity of Expat, this may be another argument for >using a simpler thing like YAML. (Assuming YAML is a simpler thing.) > >Amitha. We use expat in VTK for the XML based file formats of VTK. expat is very small, and works well. -Bill |
From: Ian S. <ian...@st...> - 2006-01-09 16:49:57
|
Amitha Perera wrote: > Just after I wrote the previous message, it occured to me that I was > writing about XML output, but not realizing that a output-only > serialization library is often useless. Thus, XML output implies XML > input, which most likely implies a dependency on an external library. > expat looks simple and small enough - and the license is liberal enough (MIT) - that we could just copy it directly into vsl. No v3p dependencies needed. Ian. |
From: Gehua Y. <ya...@rp...> - 2006-01-10 17:36:25
|
I would love to have either XML or simple text (or both) serialization capability in VXL. But I have a question as the discussion progresses: Do we want to have a generalized serialization or not? Generalized serialization is, in terms of the concept, similar to what BOOST has implemented in its serialization library. (see http://www.boost.org/libs/serialization/doc/index.html ) In BOOST, an "archive" can be binary, XML, or readable text. The object to be serialized does not need to know which type of the archives is being used. In VXL, could we or do we want to take the same approach? I am aware that VXL community has decided not to bring in BOOST (yet). But which direction to take, i.e., a more generalized approach, or only to have XML/text specific implementation, is worth some attention. Gary |
From: Ian S. <ian...@st...> - 2006-01-10 17:50:59
|
Gehua Yang wrote: > I would love to have either XML or simple text (or both) serialization > capability in VXL. But I have a question as the discussion progresses: > Do we want to have a generalized serialization or not? > Generalized serialization is, in terms of the concept, similar to what > BOOST has implemented in its serialization library. (see > http://www.boost.org/libs/serialization/doc/index.html ) > In BOOST, an "archive" can be binary, XML, or readable text. The object > to be serialized does not need to know which type of the archives is > being used. In VXL, could we or do we want to take the same approach? It did occur to me when writing vsl, that we could retrofit vsl to handle generalised formats. It would involve modifying the signature of every vsl_b_read and vsl_b_write function/method to vsl_b_read(stream& input, T& value, cost string & label). There are over 5000 calls to vsl_b_read() in Manchester's code so adding this label support might take us some time. On the question of is it worth it. If lots of people want XML, then I guess it would be silly to need two separate APIs - and one for XML and one for vsl's binary format. By modifying the existing vsl framework - then those of us who use vsl heavily would get XML support relatively cheap. Ian. |
From: Amitha P. <pe...@cs...> - 2006-01-10 18:23:49
|
On Tue 10 Jan 2006, Gehua Yang wrote: > I would love to have either XML or simple text (or both) serialization > capability in VXL. But I have a question as the discussion progresses: > Do we want to have a generalized serialization or not? While I'm in favour of unified approaches in general, this might not hold for XML. Consider struct person { unsigned age; bool student; }; The XML version of this would look something like <person> <age> 89 </age> <student> false </student> </person> In principle, the XML fragment <person> <student> false </student> <age> 89 </age> </person> would store the exact same data. This implies the need to somehow tag the data with semantically meaningful names. This is not necessary in the current serialization, and, as far as I can tell, in the Boost version. Of course, it may be that the current XML proposal won't handle this anyway. In which case I have to ask: what is the point of using XML, other than the feel-good aspect of implementing the current buzzword? Amitha. |
From: Gehua Y. <ya...@rp...> - 2006-01-10 19:32:24
|
Amitha Perera wrote: >This implies the need to somehow tag the data with semantically >meaningful names. This is not necessary in the current serialization, >and, as far as I can tell, in the Boost version. > > > > To tag data with names is, to some degree, unavoidable. Even YAML uses name-value pair for readable text output. (See http://www.yaml.org/start.html). Though it is not necessary, BOOST provides with a way for tagging. The name-value-pair in BOOST is explained at: http://www.boost.org/libs/serialization/doc/wrappers.html#nvp The point here is that, if we want to do readable text or XML serialization, we need tags, which is incompatible to current vsl design. As Ian has expressed, it will be non-trivial to change and to implement the new scheme. Gary |
From: Peter V. <pet...@ya...> - 2006-01-13 19:40:47
|
--- Amitha Perera <pe...@cs...> wrote: > ... not realizing that a output-only serialization library is often useless. > Thus, XML output implies XML input, which most likely implies a > dependency on an external library. Not necessarily. vsl only needs to successfully parse XML which it wrote itself. So I'm in favour of creating functions called vsl_x_write & vsl_x_read, without any dependency whatsoever on Expat or any other v3p library. -- Peter. |
From: Amitha P. <pe...@cs...> - 2006-01-09 16:33:53
|
Ian Scott wrote: > Gamze Tunali wrote: > >I used a basic XML element class from bxml to seperate > >the formatting decision, but if we strictly against > >depending on another package in vgl and vnl, I can > >basically write to the stream directly in vgl_xio and > >vnl_xio. Since vsl is used for vgl_io and vnl_io, > >maybe we can create a basic XML element class there > >instead. The core libraries should not depend on anything not in core or v3p. > I think it would be wise to add a basic XML element class to vsl. I seem > to remember that bad things happen if you don't maintain an acyclic > dependency graph between the modules (as well as between the libraries.) > At the very least, when CMake'ing for the first time, the vnl/xio > direction will be trying to reference a library (bxml) that CMake hasn't > come across yet. Acyclic dependencies are a must. More than that, the build order should match the dependency order, otherwise it raises all kinds of difficulties. The CMake error is a recognition of these difficulties, and is not the source of the difficulties. Amitha. |