On Fri, Apr 17, 2020 at 03:16:58PM +0000, Kent Watsen wrote: > [changing subject line] > > > On Apr 17, 2020, at 4:16 AM, Juergen Schoenwaelder > > <[email protected]> wrote: > > > > On Fri, Apr 17, 2020 at 01:13:54AM +0000, Kent Watsen wrote: > >> > >>>>>> PS: the "token” type add discussion from before never completed > >>>>>> (again, modeled after xsd:token) > >>>> > >>>> What about this? > >>>> > >>> > >>> What would this type be good for? Any models already using something > >>> like this? > >> > >> > >> Not in a standard model, that I’m aware of but, back at Juniper, I had a > >> typedef for this that I used as a basis for so many things, but mostly > >> things intended to be identifiers of sorts, whereby having whitespace > >> didn’t make sense. > >> > > > > This type does not eliminate whitespace, it only reduces multiple > > consecutive whitespaces to one. > > Leading/trailing whitespace :sigh: Too pedantic much? > > Please, think about the gazillion models where there is this: > > leaf name { > type string; > description ”An arbitrary name for the…”; > } > > It’s obvious the name shouldn’t contain paragraphs of text or, in general, > non-printable characters of any sort, or preceding/trailing space characters. > Given this preponderance of this use case and the history of module-writers > not defining the necessary pattern statements, a “token” type would be > welcomed. For instance: > > leaf name { > type token; > description ”An arbitrary name for the…”; > } >
xsd:token only collapses white space, it does not solve the problem you are talking about. And some people have argued in the past that sane operators will not put weird characters into their names. If I were to define an identifier type, I would consider to disallow white space instead of collapsing white space. Frankly, if your code can deal with one whitespace, it likely can deal with two. While the LMAP model was developed, I had a restricted identifier type in the LMAP data model. I then implemented the code to enforce the restriction. And then I figured out that the code to escape funny characters was not much longer than the code to reject funny characters and so I ended up removing the restriction. This ties into the discussion whether YANG should do anything about normalization and so far we always ended up with declaring this to be an operational problem. If you put non-normalized strings into your config, you need to be prepared to deal with the consequences. Anyway, if we were to address this issue, then xsd:token will most likely not be the answer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
