Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Andy Bierman <[e-mail]>]

On Fri, Mar 15, 2024 at 9:42 AM Jürgen Schönwälder
<[e-mail]> wrote:

> Yes, for long XPath expressions, one likes to have short prefixes, the
> shorter the better. In other contexts, such as type definitions, one
> may want to use longer prefixes providing more context. It seems you
> can't have both at the same time. Given this inherent conflict, I am
> not sure that generally pushing for longer prefixes is a good thing.
>
> For modules with long XPath expressions, an author may consider to go
> for one character local prefixes even if they require to lookup their
> meaning in the imports (or people have modern editors that can
> dynamically show an expansion) because mutli-line XPath expressions
> with lots of repetitive substrings are pretty bad for human eyes.
>
>
Short is OK if the prefix is familiar to the reader. Like "if".
What if the writer wanted a, b, c, d, etc? Shortt but not meaningful.
It is a judgment call every time, too complex for a guideline.

The guideline only mentions short so the prefix will not conflict and
the import-stmt in
other modules will not need a different prefix.  This is only for reader
familiarity, since the
YANG compiler does not care which prefix is used.

The naming convention already established is that the SDO prefix (ietf or
iana) is not used.
It would not help readers to change it now.



/js
>

Andy


>
> On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote:
> > On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder
> > <[e-mail]> wrote:
> >
> > > I wonder which problem we are solving with adding more little rules.
> > > Perhaps a future version of YANG will do away with prefixes but until
> > > this happens, I do not think we need to add more rules about how to
> > > choose prefixes. The original intend was that they are short to keep
> > > YANG snippets concise and easy to read.
> > >
> > >
> >
> > This is the IETF Coding Conventions document, not the YANG specification.
> > Naming conventions are CLRs but often with some benefits.
> >
> > What problems?
> >
> > 1) If there are multiple modules used in imports then the reader must be
> > able to
> > easily tell the prefixes apart.  If prefixes are too short and not
> > meaningful, this task
> > gets more difficult.  I find myself constantly going back to the imports
> to
> > make sure
> > I am matching the prefix to the correct module.
> >
> > 2) If there are complex XPath expressions then prefixes that are too long
> > make the
> > expression unreadable, especially as it is chopped into "string" +
> > "string"  format
> > to fit into 72 character lines. If prefixes are too short then back to
> > problem (1).
> >
> > 3)  It is becoming more common to have vendor modules import modules from
> > multiple SDOs.
> > Prefix naming conventions are already the BCP everywhere but the IETF.
> >
> > Is it too late to start for IETF? There are many modules already with no
> > naming consistency,
> > so this would only affect new modules. There will never be consistent
> > naming of prefixes
> > so it may not be worth the change now.
> >
> >
> >
> > /js
> > >
> >
> >
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>