Lou Berger <[email protected]> writes: > 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.
Sure, and one serious issue is the complexity of the spec that makes it difficult to understand. I have always insisted that the two mechanisms - inline and use-schema - are fundamentally different concepts. The former is basically data mount while the latter is an additional mechanism for schema modularity comparable to augment. Presenting them together is IMO confusing and wrong. For the use-schema case, I would even suggest to avoid the term "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 Not at all, I wasn't sure what you meant by "our example". What I wanted to say is that I am aligned with Martin on his exposition of open issue #1 that started this thread. The mount point directly under choice is of course broken, and because of it I couldn't use the schema from the most recent NI draft revision in my presentation in Prague. I just forgot to discuss this issue with you. > 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? I was pretty clear in my previous reply: "The mount-point extension itself generates no extra node." The mount point does show up in the data tree if it is instantiated, because it it defined by a "container" or "list" statement. But the "mount-point" extension just tags this already existing data node as a mount point. > > 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, this disconnect was never noticed. Certainly I agree it would be useful to extend some of the examples so as to include a tree view of the resulting schema. > 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 You nicely illustrate the confusion between data mount and schema mount. Schema mount (or the "use-schema" approach at least) is a method of schema construction analogical to an augment. This really means nothing in terms of instance data - similarly, we don't expect instance data modelled with an augment to be augmented somehow into the data tree. The schema is constructed first and it describes constraints for a data tree. Note that this is different for the "inline" case because it relies on instance data (YANG library) appearing somehow under the mount point. Lada > > Lou > >> Lada >> >>>> Lada >>>> > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
