Re: [netmod] Fwd: New Version Notification for draft-lengyel-netmod-yang-instance-data-01.txt

[Juergen Schoenwaelder <[e-mail]>]

My plain text email reader fails on the quoting and this is usually
where I drop out of discussions since I can't follow anymore.

On Tue, Jun 26, 2018 at 05:09:56PM +0200, Balazs Lengyel wrote:
> 
>    BALAZS: I did not find anything about leading/trailing whitespace e.g. for
>    an integer in RFC 7950 either. Is it allowed/prohibited?
>

7.5.7.  XML Encoding Rules

   [...]

   Any whitespace between the subelements to the container is
   insignificant, i.e., an implementation MAY insert whitespace
   characters between subelements.

7.6.6.  XML Encoding Rules

   The value of the leaf node is encoded to XML according to the type
   and is sent as character data in the element.

Note that there is no text that arbitrary whitespace may be added by a
writer and removed by a reader. Hence, I believe for values contained
in leafs, extra whitespace is not allowed. However, between containers
and leafs whitespace is insignificant. The simple reason is that for
string values, you can't simply strip leading/trailing whitespace and
in order to treat all leafs the same, you do not strip
leading/trailing whitespace in general.

That said, some parsers may (following Postel's principle) accept
<foo> +1</foo> if the YANG definition of foo says it is an int32 but
writers should generate <foo>1</foo> (the canonical format without
added whitespace). Note that if foo is defined to be a string, then
clearly the white space belongs to the string value.

If we define a file serialization format, then the format should be
the natural canonical serialization format (and if the definition of
the serialization formats is not clear enough, then we have to fix
these definitions by filing errata).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>