On Fri, Dec 28, 2007 at 08:45:08PM -0500, Daniel Veillard wrote: > On Fri, Dec 28, 2007 at 01:53:49PM +0100, Daniel Schwager wrote: > > Hi Rich, > > > > >Unfortunately this level of detail is only in the source, and usually > > >depends on the backend (Xen/QEMU/whatever). > > > > > >If you'd like to help document these sorts of issues, then we'd welcome > > >patches. The source for this page is in libvirt CVS doc/ directory. > > > > > >http://libvirt.org/format.html > > > > I want extend the java-libvirt implementation based on the code of > > István Tóth. Therefore, I created a XSD file (XML description file). > > This could be a base for the XML-documentation. > > > > Should I post it ? > > Definitely ! > There is just a problem with XSD, basically we use the type attribute value > on the top domain element to differenciate the various hypervisors > supported and XSD is unable to validate one content model or another > based on such value. Basically you will be restricted to only one possible > content model per element in your schemas, so you will have to build > an union description. I have tried (to some extend) in the Relax-NG one > to describe the differences between the content models in type='xen' > and type='kvm' in the Schemas to allow for a more precise validation. > I tend to think it's a bit more useful to try to complete and reactualize > the RNG one. Then maybe James Clark converter tool (don't remember the > name offhand trand or something similar) will be able to provide an > XSD (or even a DTD) usable by other tools. I don't see that as a huge problem. To start off with there were several elements that were relevant for HVM, but not for paravirt Xen. As we've progressed they've converged significantly & I expect that convergence to continue. Likewise Xen vs KVM the main difference being that Xen HVM can't have an explicit kernel+initrd in the <os> block, but KVM can. I have recent patches for Xen which remove that limitation. So for XML validation I don't think its going to be that important to be able to validate different content models based on the top level type attribute[1]. > > One more question: Is there a changelist for the libvirt API between 0.3.2 and 0.4 ? > > The code based on 0.3.2 ... > > Hum, not really, there is the changelog in the http://libvirt.org/news.html > but this is not exactly an API change description. [1] Well ok, container based virt, vs OS level virt is a pretty huge difference in content model, but within those 2 families of virt technology I expect the models to be near identical. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list