Subject: [netmod] document organization

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 14:23:10 +0800

Hi,

regarding my proposed reorganization of documents: I strongly disagree with
Martin's comment on jabber that it would be a mere split of the contents into
two documents. It is certainly not true because

- we could get rid of the use-schema/inline choice in schema-mounts data: the
inline case needs to state data in the parent tree at all

- there are many CLRs that are relevant only to one of the methods, so have to
distinguish the cases in the text; for example, parent-references don't apply to
"inline"

- (most important for me) the two methods are really two different mechanisms,
and the "inline" method invites various instance-related considerations whereas
"use-schema" doesn't; it's been my experience that people keep confusing schema
construction and instance data mounting.

Lada
   
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 14:25:42 +0800

> inline case needs to state data in the parent tree at all

Sorry, I meant "no state data" here.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 15 Nov 2017 09:57:31 +0000

Hi Lada, 
If the consensus is not split the document, I think it would be useful to
formally define the “inline” and “uses” options with examples very early.
As it is, there is a brief definition of “inline” but nothing for “uses”
and one must deduct this implicitly.

Thanks,
Acee 

On 11/15/17, 1:23 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 13:14:46 +0100 (CET)

> inline case needs to state data in the parent tree at all

If this was the case, we could remove 'inline' even today from this
choice.  But we can't do that unless we don't use an extension also
for "use-schema", which I know you want to get rid of, but the WG
wants to keep.

> distinguish the cases in the text; for example, parent-references don't apply to

Correct.  OTOH with two documents you probably need additional text to
explain the relationship between them.

> construction and instance data mounting.

"inline" doesn't imply instance data mounting.  Our implementation
uses "inline" w/o instance data mounting.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 21:42:32 +0800

> for "use-schema", which I know you want to get rid of, but the WG

The WG should then give me a single technical reason why the "mount-point"
extension is superior to using a schema node identifier, as we do in augments.

The argument that it permits the data modeller to restrict the locations where
schema mount can add nodes is actually a red herring - such nodes can be added
even to containers and lists that are not labelled with "mount-point":

module foo {
    ...
    container bar {
        // no "yangmnt:mount-point" here
        ...
    }

This simple augmenting module then does the trick, at the expense of one extra
container "root":

module baz {
    ...
    augment "/foo:bar" {
        container root {
            yangmnt:mount-point unwanted-children;
        }
    }
}

> explain the relationship between them.

Not really, because there needn't in fact be any relationship whatsoever. Both
methods could still be used together but they would be explained separately.

> uses "inline" w/o instance data mounting.

Well, the embedded YANG library that describes the mounted schema is part of
instance data, so it has to be added either from elsewhere or later at run time.
If it was there from the start and wouldn't change, then there is no reason to
do it this way and one can apply the "use-schema" method.

Lada