[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Re: Documentation on the xml format



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]