Added some text to fix this but did not enforce in the relaxNG. On Mar 15, 2011, at 10:51 AM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/14/2011 04:56 PM, Cullen Jennings wrote: >> >> On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote: >> >> More comments: >> >> A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>" >> >> If a configuration document contains multiple configuration elements (and I >> guess multiple matching signature elements), then should not config_data >> been in >> fact structured the same way than kinds?, i.e. an XML fragment containing >> only >> the configuration element and the signature element for this overlay, >> extracted >> from the multiple configuration elements document? >> >> See also A.31 below. >> >> A.31. Section 1.1 'The file can contain multiple "configuration" elements..." >> >> This contradicts the RELAX NG grammar in section 10.1.1. In addition, should >> not configuration elements be structured as kind elements are, i.e. something >> like this: >> >> <overlay> >> <configuration-block> >> <configuration>...</configuration> >> <signature>...</signature> >> </configuration-block> >> <configuration-block> >> <configuration>...</configuration> >> <signature>...</signature> >> </configuration-block> >> </overlay> >> >> In this case, config_data would contain a XML configuration-block production >> (see A.31 above) >> >>> I changed the grammar to allow >> >> <overlay> >> >> <configuration>...</configuration> >> <signature>...</signature> >> >> <configuration>...</configuration> >> <signature>...</signature> >> >> </overlay> >> >>> I like the config-block would be better but it would break existing stuff >>> so I made the grammar match the existing text which seemed to allow the >>> above. Thoughts on what we should do here? I have no strong opinion - >>> fundamentally they are both about the same. > > Having no config-block makes this fragment valid: > > <overlay> > <configuration /> > <configuration /> > <configuration /> > <signature /> > <signature /> > </overlay> > > But in fact I am withdrawing my suggestion in A.30 to use the config-block in > the ConfigUpdateReq, instead of the whole overlay: There is nothing that > prevent an implementation to send a document with only one configuration and > signature element in the ConfigUpdateReq, even if the document retrieved from > the configuration server contains more than one. > > So my suggestion would be to keep thing as they are, but add text that explain > the configuration/signature elements should be interleaved and that a > signature > element applies only to the configuration element immediately preceding. > Perhaps enforcing this in the RelaxNG schema could also be a good thing. > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk1/mSQACgkQ9RoMZyVa61d/dQCeNobyVwaCD6N9Co+gGytx3swd > kpkAn0qLyJqgnMuygjIhsfgGZATawC0f > =opRp > -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
