Andy Bierman <[email protected]> wrote: > On Thu, Nov 5, 2015 at 4:50 PM, Martin Bjorklund <[email protected]> wrote: > > > Hi, > > > > Andy Bierman <[email protected]> wrote: > > > Hi, > > > > > > I asked about this text on page 156: > > > > > > > > > In statements that have any data definition statements as > > > substatements, those data definition substatements MUST NOT be > > > reordered. > > > > > > I asked why this new rule was added. > > > > It is not a new rule, it is there in RFC 6020 as well. > > > > > Then the word "reordered" needs to be clarified > > > > > In rpc/action input/output the nodes are encoded in XML in the order > > they are defined. So this rule is there to protect clients that might > > depend on that order. > > > > > But this just applies to the advertised version of the RPC. > The client should use the schema the server supports, > and the order is dictated by that version.
In general the update rules are there in order to protect old clients. If we say that the client needs to understand the revision that the server implements, then we can remove all update rules. > > > I do not see why it is needed, or how it can be enforced. > > > > > > If I add a new object to grouping A, then every place there > > > is a "uses A", a new data node will be inserted inline. > > > > Newly inserted nodes does not change the order between the old nodes. > > > > > > This is one interpretation of the term "reorder". > This interpretation is OK -- the relative order cannot be changed > but overall, any subtree can have nodes added in between > existing objects (via direct edit or uses). Ok, how about: OLD: In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. NEW: In statements that have any data definition statements as substatements, the relative order between old data definition substatements MUST NOT be changed. > > We could relax the rule and say that it only applies to input/output > > and groupings (since they might be in input/output. > > > > > OK, except the identification of objects does not depend on order. > This is kind of a CLR. Do you think we should relax the rule? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
