Re: [netmod] schema mount open issue #1

[Lou Berger <[e-mail]>]

For me usage standpoint it really would be much simpler in the model 
definition and use for the mount point to behave like a container. What are 
your technical objections to this change? Note that the encoding from a 
protocol standpoint would be the same as a container.

Thanks
Lou


On August 29, 2017 8:46:18 AM Martin Bjorklund <[e-mail]> wrote:

> Lou Berger <[e-mail]> wrote:
>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>> > Lou Berger <[e-mail]> 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
>