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: Greg Chicares
Subject: Re: [lmi] Concinnity test for "xml files"
Date: Tue, 31 Oct 2006 15:42:37 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-10-31 14:42 UTC, Evgeniy Tarassov wrote:
> 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?

Thanks for that information. I think I'll keep calling them
'xml files', in 'GNUmakefile' at least, which does some
testing that really is based on the files' nature.

>> 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).

Thanks. Would you mind updating the FSF address, too? I think you
can just copy the license-and-disclaimer block from 'menus.xrc'.
If you put the 'forbidden.make' file emailed separately in the
parent of your source directory, it will complain about
"59 Temple Place" because FSF is no longer at that address.

I see '$Id$" in 'format.xml' (I didn't check the other files).
I think you need "$Id $" with a space for replacement to occur.
I've run into that problem before, myself.

BTW, how did you ever get the substitution mode changed?
'ChangeLog' says:
  20061030T1725Z <address@hidden> [1161]
  Change cvs substitution mode to default to '-kkv'. Fix RCS Id again.
  The previous change 20061030T1206Z did not work.
after I had tried repeatedly, without much success. I'd like
to learn the right way to do this.

Oh, and also BTW, another thing I've learned is to run
'make check_concinnity' just before committing anything, and not
to modify even 'ChangeLog' after it runs...try making that target
again and it'll complain about
  Fix line ending to LF. Make files to pass 'make check_concinnity' test.

> 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.

It's painful to think that a 'lint' tool would perform a damaging
transformation, but we can't easily fix the tool ourselves.

> 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.

If 'xmllint' really just makes '.xsl' files worse, then I guess
we should just write them the way we want, for readability, and
exempt them from the 'xmllint' test. Is there no option for
'xmllint' to make it accept what we want to do, though? It has
dozens of options, and I've never tried to understand them.
Or, if that doesn't work, and the things 'xmllint' dislikes
are limited in scope, we can filter them out of the 'diff'
comparison, so that 'make check_concinnity' will ignore them.




reply via email to

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