Lou Berger <[email protected]> wrote: > On 08/29/2017 03:37 AM, Martin Bjorklund wrote: > > Lou Berger <[email protected]> wrote: > >> Lada, > >> > >> > >> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote: > >>> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400: > >>>> Lada, > >>>> > >>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote: > >>>>>> Can you please take a look at it and see if we have any other > >>>>>> disconnects? > >>>>> This is really scary. > >>>> I agree! > >>>> > >>>>> How can we expect poor data modellers to understand the > >>>>> concept if we have such fundamental disconnects, after so many hours of > >>>>> discussing it? > >>>> This highlights why getting the text in (any) document is so important, > >>>> and why discussions shouldn't be viewed as being closed until the impact > >>>> on the text is agreed to! > >>> I think many people still don't make much distinction between schema mount > >>> (manipulation of the schema) and data mount. I still believe we need to > >>> clearly > >>> separate these two concepts, preferably using two different mechanisms. > >> > >> Frankly, I'm focused on removing blocking issues on the current WG > >> deliverable, i.e., schema mount. > >> ... > >>>> Lou > >>>> > >>>> PS is your view aligned with martin or our example? > >>> If you mean shifting the XPath context node to the mount point instance, > >>> then > >>> yes. > >> > >> funny, you answered yes to a choice! I was asking if you think the > >> mount point shows up as a node in the data tree, i.e., as shown in the > >> example in > >> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1? > >> > >> from my perspective and my co-authors in the RTG area using schema > >> mount, we've never heard of a (filesystem) mount point that doesn't show > >> in the (directory) structure and this is the mental analogue we've been > >> assuming. Since there never was an explicit example/discussion or text > >> to dissuade us of this > > > > The current text says: > > > > A "container" or "list" node becomes a mount point if the > > "mount-point" extension (defined in the "ietf-yang-schema-mount" > > module) is used in its definition. > > interesting, read that a few times to (now) get the gist of your intent. > > > > > But of course we should clarify this. > > > > > > >> , this disconnect was never noticed. Certainly > >> this needs to be explicit in the document (either way). The following > >> change could be made to the schema mount draft (at a minimum): > >> > >> OLD > >> A mount point defines a place in the node hierarchy where > >> other data models may be attached. A server that implements a > >> NEW > >> A mount point defines a node in a data tree under which > >> instances of > >> other data models may be attached. A server that implements a > > > > I strongly object to letting the extension define a new data node. > > > This would be a new type of data node that presumably look a lot like > > a container, > > agreed, just like a mount point looks a lot like a directory in a unix > file system. > > > and you'd have to define all sorts of rules for this new > > node (how it is encoded in XML, JSON, CBOR; how it is handled in > > edit-config, how it is mapped to RESTCONF resources etc etc). > > I'm don't see this, the rules would be the same as a container, as in > "mount points in data trees are encoded identically as containers". > > > > > If you thought that the extension implicitly creates a node, adding an > > explicit container won't do any harm; it will not change the schema > > tree from what you thought it was. > > Well we could make this work, but it feels like every model that uses > schema has added complexity to its definition and use to perhaps avoid > making some minor tooling changes. Keep in mind that any use of the > mount point extension will required changes in tooling. > > > > > But I think we should also restrict the mount-point extension so that > > there cannot be more than one mount-point in a given container. > > > In this case, I'd go further and say that the only thing in the > container (of the module schema) is the mount point and a mount point > extension is only valid within a container. (Then the semantics are the > same as we expected, just the syntax is different.)
I was thinking about this as well, but I thought that maybe rejecting any other data node is a CLR. Maybe there is a good use case for e.g. an action in a mount point. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
