On Sat, Jan 23, 2010 at 05:43:41PM +0200, Dan Kenigsberg wrote:
> On Thu, Jan 21, 2010 at 03:33:21PM +0100, Daniel Veillard wrote:
> > On Tue, Jan 05, 2010 at 02:51:06PM +0200, Dan Kenigsberg wrote:
> > > Please consider something along these lines. Without it, pretty-printed
> > > domxml is rejected due to the whitespace before uuid, and long long
> > > string of hexadecimal digits is accepted.
> > > ---
>
> >
> > Yes that looks fine to me and testing for NUL termination sound
> > important, ACK,
> >
> > pushed, thanks !
>
> Thank you. Though since I've sent that, I noticed that surrounding
> whitespace is a more general problem of xml text nodes, such as the
> <os><type> element.
>
> Should libvirt consider any surrounding whitespace as insignificant?
> What's usually done in the xml world?
From an XML viewpoint, all whitespeces outside of markup constructs
(for example spaces spearating attributes on an element) are considered
significant and must be reported to the application, at least at the
parser level [1]. Any treatment after that is considered application
specific. The outcome of SGML experiene is that it's basically
impossible to make heuristics on what might be spaces used for markup
indentation vs. actual user content, so teh decision was to make
everything significant by default.
IMHO we should not try to cleanup spaces by default, e.g. in paths
<device>/dev/foo </device>
should lead to an error at runtime. OS type is a bit on the edge because
"Linux" "linux" should probably be considered equivalent, so why not
cleanup a leading or trailing space.
Daniel
[1] okay there are some subtle exceptions in attribute content
if the attributes are declared of some types in the DTD but we don't use
DTD in libvirt anyway
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list