lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Style checking for xml files


From: Greg Chicares
Subject: [lmi] Style checking for xml files
Date: Tue, 22 May 2007 03:41:04 +0000
User-agent: Thunderbird 1.5.0.10 (Windows/20070221)

We've used 'xmllint' (via 'make check_concinnity') to check the
format of '.xrc' files before committing changes, and it's been
really helpful for making sure indentation remains meaningful,
as well as for ensuring the validity of the changes. Basically,
we just run these files through 'xmllint' to reformat them, and
diff the result against the file.

That's served us well, and I'd like to expand it to encompass
other xml files, which for now are excluded from that makefile
target's scope. Here
  http://cvs.sv.gnu.org/viewvc/lmi/lmi/GNUmakefile?r1=1.86&r2=1.87
is a diff that happens to highlight a recent comment about this.
I would hope that we could make these files pass this test,
removing each from the "unclean" list when it's made to pass.

The most difficult part seems to be the '.xsl' files. There's
some entity (equivalent to nonbreaking space, IIRC) that gets
translated into some strange (unicode?) character by 'xmllint'.
There are some blocks that 'xmllint' would turn into really
long lines (I saw one that would be four hundred characters),
and that seems to make the code less readable. Does 'xmllint'
have options to deal with issues like those?

What's most important to me is readability. This test has
saved us from problems like
                <object class="sizeritem">
                    <flag>wxGROW|wxALL</flag>
                    <border>2</border>
                    <object class="wxFlexGridSizer">
                        <object class="sizeritem">
                        [...snip hundreds of lines...]
                      [accidentally outdent closing tag...]
                    </object>
                </object>
            </object>
where bad indentation impedes understanding. There may be
other benefits that this or some other tool could provide.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]