lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Concinnity test for "xml files"


From: Evgeniy Tarassov
Subject: Re: [lmi] Concinnity test for "xml files"
Date: Tue, 31 Oct 2006 15:42:40 +0100

On 10/25/06, Greg Chicares <address@hidden> wrote:
First of all, I seek a generic term for
  *.xml *.xrc *.xsd *.xsl
and have been calling them "xml files", for they all contain
  <?xml?>
; but is there a concise term that's more appropriate?

I don't know myself what could be another term for these xml resources
used in lmi. We are using numerous technologies which are not groupped
together and are seen as different applications for xml.
XML itself (http://www.w3.org/XML/)
XSL (http://www.w3.org/Style/XSL/)
XMLSchema (http://www.w3.org/XML/Schema)

Maybe something completly different describing more the purpose of the
files than theirs nature could be used? Something like
$report_source_files?

At any rate, please either make the files described above pass
'make check_concinnity', or let me know that it's not a good idea
to try. Things like the FSF address are easy and should be done.
But there's another test that passes files through 'xmllint' and
makes sure that filter doesn't change them; is that inappropriate
for '*.xs[dl]' files? We've found that test handy for catching
malformed xml before we commit it.

Done. Commited yesterday to xml-gnome-branch (20061031T0101Z).

However there is still one hidden problem with common.xsl and
tab_delimited.xsl which is not resolved. These files are used to
produce TSV and any extra-space or an unwanted-LF could break the
output. Both files were formatted in a way to exclude any possibility
of such a additional space or LF, but after xmllin reformatted the
files it is unreadable.

I will read specs about XSLT and spaces and will make files
human-readable. ATM i'm not sure how exactly libxslt handles spaces
and what measures should be taken to control exactly what goes into
the output.

This isn't urgent: it would be good enough to address it within
the next couple of weeks.

It should not hold back calculation summary testing because the
template as it is now should work as intended. Only the readability
suffers.




reply via email to

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