Re: [xml] final output filtering?

[Daniel Veillard <veillard redhat com>]

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

  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

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