On Wed, 2017-11-15 at 13:14 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <[email protected]> wrote:
> > 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
> 
> 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.

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;
        }
    }
}


> 
> > - 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"
> 
> Correct.  OTOH with two documents you probably need additional text to
> 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.

> 
> > - (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.
> 
> "inline" doesn't imply instance data mounting.  Our implementation
> 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

> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Reply via email to