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.)
