Redundant Line Generated in SAD File

[mcarrick]

When using OWD to generate the XML files for a waveform, an extra line is generated in the .sad.xml file. The first couple of lines from the .sad.xml file with the extra line is listed below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE softwareassembly SYSTEM "../../xml/dtd/softwareassembly.dtd">
<!--Created with OSSIE WaveDev? Beta Version 0.6.2-->
<!--Powered by Python-->
<!DOCTYPE softwareassembly SYSTEM 'dtd/softwareassembly.dtd'>
<softwareassembly id="DCE:016c9b40-efbb-11dc-a6f3-001d092f0ea2" name="OSSIE::proj">

Running nodeBooter on the DAS file gives the error: "The element softwareassembly already exists". After removing the 5th line (<!DOCTYPE softwareassembly SYSTEM 'dtd/softwareassembly.dtd'>), nodeBooter works correctly and the waveform can be run.

I do not have this problem with my VMWare image. I have recently installed OSSIE 0.6.2 through the tarball on the website along with the dependencies following the steps listed in the 0.6.2 User Guide. I tried downloading the latest version of OWD from the repository, but it still prints the redundant line.

[balister]

I ran through creating a waveform that should look like ossie-demo and created a SAD file without this problem. This was done in a vm I had previously installed 0.6.2 from the tarball.

Maybe there is some kind of weird order of operation dependency?

[mcarrick]

Replying to balister:

I ran through creating a waveform that should look like ossie-demo and created a SAD file without this problem. This was done in a vm I had previously installed 0.6.2 from the tarball. Maybe there is some kind of weird order of operation dependency?

I've talked with Drew about this he suggested I look at application_gen.py and _sad.xml.tmp (under /sdr/tools/WaveDev/wavedev/XML_gen), where the two redundant lines are coming from. Both the tarball and the VMWare image have the same exact application_gen.py and _sad.xml.tmp files. The SAD template has the line:

<!DOCTYPE softwareassembly SYSTEM "dtd/softwareassembly.dtd">

The line is not printed in the VMWare image, however it is printed in the tarball version.

[balister]

Yeah, I had poked through these files. I'm not sure why we see a difference between our two installations from the tarball. I seriously doubt it has anything to do with vmware.

I'm wondering if there are multiple paths to get owd to generate the waveform and they execute slightly different code, for example generating via a right click versus generating from a menu pick. I tend to do things one way that works for me, even if there are multiple paths to do the action. This habit makes me a bad tester, but very good at getting useful work out of buggy software :)

[mcarrick]

I talked with Dr. Dietrich about the problem and he commented on the fact that Drew and I were the ones that had problems with it, and we're the only ones using FC8. What version of Fedora is your VMWare image running?

[balister]

For completeness:

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

This is the only machine I have installed 0.6.2 on from the tarball.

[DrewCormier]

I actually originally noticed this problem on OSX 10.5. Python 2.4.3.

My desktop (FC8) is running python 2.5.1. My desktop did however have a working version of OWD on it not too long ago. I noticed the problem the second time I downloaded the 0.6.2 branch. I am highly suspicious that my last statement is suspect (I'm very confused as to what version I was using, that worked, prior to my last update).

I agree with Philip on the "multiple paths" issue. I looked into the code a little, but I can't find anything like this. Unfortunately, we might just have to stick some print statements in both the working and broken versions to find out why something is either skipped or overwritten in the working case.

I suspect we are looking at one of those "outside the box but right in front of your face" type issues :/

[jgaeddert]

This ticket is an artifact of moving from Amara to python's xml.dom.minidom module. The minidom module will properly export the DOCTYPE line, while the old way requires the line to be added manually.

[DrewCormier]

One of them is sometimes there, and one is always there. I believe we just need to get rid of the one that it sometimes there. I think the one that is always there is in the template.

[jgaeddert]

We should not be using templates for XML parsing. The built-in python module takes care of ALL of this and is much easier to manipulate. Look at application_gen.py. There are about 4 lines that add a redundant DOCTYPE line, via

postProcessed_sad.writelines(u'<!DOCTYPE softwareassembly SYSTEM \"../../xml/dtd/softwareassembly.dtd\">\n')

One of these lines is commented out (for the DAS file, I think) and it works fine.

These lines exist in component_gen.py as well. With the xml.dom.minidom module, there is no need to post-process XML. This includes all the XML beautify code which isn't used.

[DrewCormier]

I made a change in 0.6.x that might resolve this problem. Needs testing.

[DrewCormier]

I have tested this with a few waveforms and it seems to be working fine. I also updated the generation of DeviceManager?.dcd.xml, component.prf.xml, component.scd.xml, and some others that had the same problem.

I made the changes in the 0.6.x branch, and I'm going to go ahead and close this. If anyone has any problems related to this in the future, please reopen the ticket.

[jgaeddert]

I checked in some changes with r7383 for 0.6.x that should fix this problem. I know that this ticket is already closed, but I can almost guarantee that the redundant DOCTYPE lines won't be generated.