[libvirt] [PATCH] schema: interleave domain name and uuid with other elements

Ján Tomko jtomko at redhat.com
Thu Dec 17 14:07:25 UTC 2015


On Thu, Dec 17, 2015 at 01:28:28PM +0000, Daniel P. Berrange wrote:
> On Thu, Dec 17, 2015 at 02:18:49PM +0100, Michal Privoznik wrote:
> > On 17.12.2015 13:56, Ján Tomko wrote:

[...]

> > > diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> > > index 4804c69..01d99f0 100644
> > > --- a/docs/schemas/domaincommon.rng
> > > +++ b/docs/schemas/domaincommon.rng
> > > @@ -30,8 +30,8 @@
> > >    <define name="domain">
> > >      <element name="domain">
> > >        <ref name="hvs"/>
> > > -      <ref name="ids"/>
> > >        <interleave>
> > > +        <ref name="ids"/>
> > >          <optional>
> > >            <ref name="title"/>
> > >          </optional>
> > > 
> > 
> > This is rather tricky. I'm not against the change, but 'ids' is defined as:
> > 
> > <optional attribute/>
> > <interleave>
> >   <elem name/>
> >   <optional elem uuid/>
> > </interleave>
> > 
> > Thing is, if "ids" would ever get second in the master <interleave/>
> > shown in your patch, the attribute might refer to a different element.

The order in interleave does not matter. The attribute refers to the
parent element, not the last mentioned element. Or did you mean
something else?

> > But I guess that would fire plenty of failed cases in our test suite, right?
> > 

IIUC that would be a loosening of the schema, so it would probably not.

> > ACK then.
> 
> IMHO, we could just inline the 'ids' content in this caller - there's
> no real benefit in having a separate "ids" define, and the clear
> downside that you mention

I have no objections to inlining it, I just don't see the downside.

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151217/99ad8167/attachment-0001.sig>


More information about the libvir-list mailing list