Subject: Re: [netmod] issue Y56 UTF8 non-characters

From: Randy Presuhn <[email-masked]>
Date: Tue, 28 Oct 2014 16:55:06 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Oct 28, 2014 1:46 PM
>To: Martin Bjorklund <[email-masked]>
>Cc: [email-masked], [email-masked]
>Subject: Re: [netmod] issue Y56 UTF8 non-characters
...
>> > In any case, this needs to be in narrower terms than "YANG module".
>> 
>> Can you elaborate, I do not understand what you mean.
>> 
>> > It would not be good to break RFC 6020 section 9.4.2.
>> 
>> ... specifically I do not understand how this section would be
>> affected?
>> 
>
>Perhaps Randy asks what happens to default values?

String literals in general, but default values are a good example
of something which IMO should *not* be "touched" by normalization
of things like enum labels.

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 29 Oct 2014 10:03:07 -0700 (GMT-07:00)

Hi -

>From: Martin Bjorklund <[email-masked]>
>Sent: Oct 29, 2014 12:15 AM
>To: [email-masked]
>Cc: [email-masked]
>Randy Presuhn <[email-masked]> wrote:
>> Hi -
>> 
>> >From: Martin Bjorklund <[email-masked]>
>> >Sent: Oct 28, 2014 2:21 PM
>> >To: [email-masked]
>> >What problem is solved by doing normalization of a YANG module?
>> >
>> >(I can think of a few, but they don't seem very realistic, e.g. this
>> >would be legal but confusing:
>> >
>> >  leaf swedish-fish {
>> >    type enumeration {
>> >      ...
>> >      enum ÅL;
>> >      enum ÅL;
>> >      ...
>> >    }
>> >  }
>> >)
>> 
>> In addition to ÅL, there's a third "spelling" for ÅL.
>>
>> It gets *much* worse in Vietnamese.  A common word like "đường" ("street")
>> can literally be "spelled" 20 different ways in Unicode, depending on one's
>> choice of precomposed and "combining" options.  The situation is similarly
>> painful in Korean.
>> 
>> My concern is mostly for operators using text-based tools and printed
>> documentation.  When typing in a request, how much does "spelling"
>> matter?  How does an operator know whether to type "ÅL" or "ÅL",
>> or which way to "spell" "đường"?
>
>But isn't this a bigger problem for instance data, i.e., strings?

Yes, that's a big problem, but it's a *separate* problem,
and involves considerations that don't exist in the case of,
say, enum labels.  Instance data strings are subject to the
quirks of whatever resource is being managed.  Unless you're
willing at the level of the metamodel to require all managed
resources' implementations to conform to a particular normalization
form for instance data, you're stuck with permitting the protocol
to carry them all (including *none*), and to the extent that specific
models represent values that may be manifested by implementations,
the modeling language has to be able to represent those values.

I think that horse has already left the barn, though in the
future it might be useful to define normalized string subtypes,
particularly for keys.

>> But it's also a question for module writers.  Do they have to "spell"
>> their labels consistently in those cases where there are references to
>> them from within or between modules?
>
>If it comes down to this, I think I can live with this.

How does an operator with printed documentation know how the
module writer has chosen to spell something?  How does the
writer of another module hoping to import something know?
What does it mean if someone (inadvertently) changes the
spelling from one version to the next?

Randy