[Libvir] Re: Documentation on the xml format

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.
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 ? 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 ... regards Danny ------------------------------------------------------------------- DT Netsolution GmbH - Taläckerstr. 30 - D-70437 Stuttgart Geschäftsführer: Daniel Schwager, Stefan Hörz - HRB Stuttgart 19870 Tel: +49-711-849910-32, Fax: -932 - Mailto:daniel.schwager@dtnet.de

On Fri, Dec 28, 2007 at 01:53:49PM +0100, Daniel Schwager wrote:
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.
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 ?
Certainly! There's also a (slightly out of date now) RelaxNG schema here: http://libvirt.org/libvirt.rng The 'http://libvirt.org/format.html' page was useful in the beginning as a gentle introduction to the domain XML, but I feel we need to provide a formal reference of all elements & attributes we support. I wonder if Daniel has some magic to auto-generate a nice HTML reference based on embedded docs in a schema file....
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 ...
Various sources: - ChangeLog - details each individual commit - NEWS - details significant enhancements between releases - http://libvirt.org/hvsupport.html details when each drivier implements a particular API. Dan. -- |=- 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 -=|

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 ? Certainly!
I create a small xmlbeans based XSD/XML validator and give it a WebCFG Frontend. You can access it via http://public.dtnet.de/webcfg I insert my base XSD file as a template to the frontend. Also a small XML-file is available as a template. Please feel free to modify/change the XSD by copy/paste your files to the webform.
There's also a (slightly out of date now) RelaxNG schema here: http://libvirt.org/libvirt.rng Maybe someone who knows the the current schema can modify the XSD file ...
The 'http://libvirt.org/format.html' page was useful in the beginning as a gentle introduction to the domain XML, but I feel we need to provide a formal reference of all elements & attributes we support. I wonder if Daniel has some magic to auto-generate a nice HTML reference based on embedded docs in a schema file....
Beside of the html-docu there should be a formal validator... regards Danny

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.
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.
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. thanks, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

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.
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 -=|
participants (3)
-
Daniel P. Berrange
-
Daniel Schwager
-
Daniel Veillard