Re: [xml] final output filtering?
- From: Daniel Veillard <veillard redhat com>
- To: Peter Jacobi <pj walter-graphtek com>
- Cc: XML List <xml gnome org>
- Subject: Re: [xml] final output filtering?
- Date: Tue, 10 Jun 2003 06:44:28 -0400
On Tue, Jun 10, 2003 at 11:01:05AM +0200, Peter Jacobi wrote:
When writing with the default file reader
fd = fopen(path, "w");
platform dependant line break processing (at least on WIN32)
will be delegated to the C runtime library.
I don't know zilch about the Mac platform, but let assume for the
sake of argument that it works like WIN32 and fopen without
"b" will do platform dependant line break processing.
Well clearly it doesn't since
Then, if I'm not mistaken, libxml2 will output with local line
break conventions and everything will work fine, unless you want
to produce under WIN32 a file with Mac conventions or the like.
But precisely, I want libxml2 to be platform independant. The exact
same sequence of bytes should come out of it given the same sequence
of bytes in input. This is *precisely* the essence of the line end
normalization requirement of XML, all platforms must behave the same
independantly of their convention, the locale of the user or whatever
specious treatment made to mark EOL. On EBCDIC systems too, the end
of line for XML 1.0 has to be the one from ASCII or the tools simply
breaks. This is all about agreeing on a standard way of processing things.
On the other hand, as libxml2 output already will give different
files, whether run on WIN32 or not, it seems not to be outruled
by principal reasons, to do the output line break conversion
in libxml2 instead of by the C runtime.
Libxml2 tries to avoid this precisely by forcing the binary output.
Something like xmlSetOutputLineBreakSeparator. Of course
it will add some more complications, but I see no reason
not to accept a patch from Chris on this issue.
Well, it's one more "special case", forcing a non-conformant behaviour
since modifying the EOL do change teh infoset of the document. It's
not an XML processing problem, it's an editor rendering problem pushed
back to the wrong place. There is 1 person asking for this non-conformant
behaviour. This can be handled already by redefining the I/O layer of
libxml (register your own set of I/O handler for file accesses as documented
on http://xmlsoft.org/xmlio.html#Example2 or by using
The library allows to redefined the I/O layer, precisely for this
kind of custom purpose, my answer is to use that capability rather than
introducing a non-conformant processing mode in it.
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev