Subject: [Netmod-ver-dt] Proposal to remove "common-packages" list again

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 7 Feb 2020 11:38:08 +0000

I'm wondering whether having the "common-packages" list is worth the extra complexity.  Particularly because this problem can also be solved (in a more flexible way) in the /packages top level list.  I.e. given that package definitions can be hierarchical, you can just define a "common-schema" package, with each datastore including that "common-schema" along with any datastore specific deviations.  It also seems to be better if there is only one way to solve this problem.

I think that this would make the schema slightly shorter/simpler and perhaps is a bit easier to explain the relationships.  Hence, I'm not proposing that we remove "common-package" and revert back to the slightly more verbose, but simpler representation that we had previously.  Any thoughts?

Old schema (without the change):

module: ietf-schema-selection
  +--rw schema-set-selection!
     +--rw selectable*   -> /schema-set-selection/schema-set/name
     +--rw default       -> /schema-set-selection/selectable
     +--rw custom* [name] {custom-schema-set}?
     |  +--rw name               string
     |  +--rw description?       string
     |  +--rw included-schema*
     |          -> /schema-set-selection/schema-set/name
     +--ro schema-set* [name]
        +--ro name                 string
        +--ro partial?             empty
        +--ro common-package* [name version]
        |  +--ro name        -> /pkgs:packages/package/name
        |  +--ro version     leafref
        |  +--ro checksum?   leafref
        +--ro datastore* [name]
        |  +--ro name                  ds:datastore-ref
        |  +--ro read-only?            empty
        |  +--ro additional-package* [name version]
        |     +--ro name        -> /pkgs:packages/package/name
        |     +--ro version     leafref
        |     +--ro checksum?   leafref
        +--ro compatible-with*
        |       -> /schema-set-selection/schema-set/name
        +--ro custom-selectable! {custom-schema-set}?
           +--ro combinable*
                   -> /schema-set-selection/schema-set/name

Proposed schema (without the change):

module: ietf-schema-selection
  +--rw schema-set-selection!
     +--rw selectable*   -> /schema-set-selection/schema-set/name
     +--rw default       -> /schema-set-selection/selectable
     +--rw custom* [name] {custom-schema-set}?
     |  +--rw name               string
     |  +--rw description?       string
     |  +--rw included-schema*
     |          -> /schema-set-selection/schema-set/name
     +--ro schema-set* [name]
        +--ro name                 string
        +--ro partial?             empty
        +--ro datastore* [name]
        |  +--ro name                  ds:datastore-ref
        |  +--ro read-only?            empty
        |  +--ro package* [name version]
        |     +--ro name        -> /pkgs:packages/package/name
        |     +--ro version     leafref
        |     +--ro checksum?   leafref
        +--ro compatible-with*
        |       -> /schema-set-selection/schema-set/name
        +--ro custom-selectable! {custom-schema-set}?
           +--ro combinable*
                   -> /schema-set-selection/schema-set/name

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 7 Feb 2020 14:37:37 +0000

On Feb 7, 2020, at 06:38, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:

I’m wondering whether having the “common-packages” list is worth the extra complexity.  Particularly because this problem can also be solved (in a more flexible way) in the /packages top level list.  I.e. given that package definitions can be hierarchical, you can just define a “common-schema” package, with each datastore including that “common-schema” along with any datastore specific deviations.  It also seems to be better if there is only one way to solve this problem.

I think that this would make the schema slightly shorter/simpler and perhaps is a bit easier to explain the relationships.  Hence, I’m not proposing that we remove “common-package” and revert back to the slightly more verbose, but simpler representation that we had previously.  Any thoughts?

This email is confusing.  Are you saying you _are_ proposing to remove common-schema and opt for the shorter hierarchy?  If so, I agree.  I think the second tree instance is much easier to read and comprehend.

Joe

_______________________________________________
Netmod-ver-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 7 Feb 2020 14:48:27 +0000

Hi Joe,

From: Joe Clarke (jclarke) <[email-masked]>
Sent: 07 February 2020 14:38
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netmod-ver-dt] Proposal to remove "common-packages" list again

This email is confusing.  Are you saying you _are_ proposing to remove common-schema and opt for the shorter hierarchy?  If so, I agree.  I think the second tree instance is much easier to read and comprehend.
[RW]
Yes, that is what I’m proposing.  Apologies that my original email wasn’t more clear!

Thanks,
Rob

Joe