On Wed, Feb 28, 2018 at 09:40:11 +0000, Daniel Berrange wrote: > On Wed, Feb 28, 2018 at 10:34:51AM +0100, Erik Skultety wrote: > > On Tue, Feb 27, 2018 at 05:15:30PM +0000, Daniel P. Berrangé wrote: [...] > > By having the separate <sev> element you can make the sub-elements depend on > > this parent element, since you can't expect other vendors to favour <cbitpos> > > which add burden to the documentation to make it clear. Of course, the price > > you pay for this is a more complex XML structure. The parser can parse different things depending on the model name. Also the schema has provisions for this. The only slightly more complicated part is providing examples in the documentation, since you'll need to repeat the block with different model. > > <launch> > > <security> > > <sev> > > <sev_specific_elements/> > > </sev> > > </security> > > This is not the way we usually do things - we wuld have a type="sev|..." > which determines what child elements are permitted, as illustrated in > the example above. > > > <other_security_unrelated_validation_options/> > > </launch> > > I think the extra level of nesting is uneccessary Also new elements are ignored by older libvirt (since schema validation is not turned on in all cases) while new values for an enum can be properly validated and rejected.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
