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. 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, 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). 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. 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. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
