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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list