Re: [netmod] schema mount open issue #1

[Ladislav Lhotka <[e-mail]>]

Lou Berger <[e-mail]> 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