Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Tue, Nov 17, 2015 at 11:03 PM, Ladislav Lhotka  wrote:

>
> > On 17 Nov 2015, at 21:18, Andy Bierman  wrote:
> >
> >
> >
> > On Tue, Nov 17, 2015 at 12:11 PM, Ladislav Lhotka  wrote:
> >
> > > On 17 Nov 2015, at 21:03, Ladislav Lhotka  wrote:
> > >
> > >>
> > >> On 17 Nov 2015, at 18:08, Andy Bierman  wrote:
> > >>
> > >>
> > >>
> > >> On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka 
> wrote:
> > >>
> > >>> On 17 Nov 2015, at 11:19, Robert Wilton  wrote:
> > >>>
> > >>> As a possible compromise, what about something like:
> > >>>
> > >>> The JSON encoding defines that anyxml may be encoded in whatever way
> the implementor finds useful, or even not at all.  If a preferred
>  custom encoding is not being used, then it is suggested that anyxml data
> be encoded as a string containing XML to maximize legacy interoperability.
> > >>
> > >> While this is quite complicated, I don't think it helps in any way.
> There are no anyxml objects that need to be encoded, so what an implementor
> finds useful is totally irrelevant. The yang-json spec should state what's
> permitted as the content of an anyxml instance in JSON encoding, and that's
> all. To this end, the current text is IMO sufficient, except that the
> "otherwise" part may be misleading - but it's not necessary.
> > >>
> > >> Note that XML-in-JSON-string has its share of problems and may not be
> interoperable either: the content of an anyxml instance in XML encoding
> needn't be a well-formed XML document.
> > >>
> > >>
> > >> So now anyxml includes XML that is not even well-formed?
> > >
> > > Sure. First, in the XML encoding the anyxml chunk may inherit
> namespace and entity declarations from the outer context. This could be
> corrected by adding these declarations to the JSON string. But then also,
> if we have
> > >
> > > anyxml foo;
> > >
> > > then this is a valid XML encoding
> > >
> > > 
> > >  
> > >  
> > > 
> > >
> >
> >
> > (!) The internal representation of data is implementation-specific.
> >
> >
> > > but the JSON string value
> > >
> > > "foo": ""
> >
> > Sorry, this was supposed to be
> >
> > "foo" : ""
> >
> >
> >
> > If the internal server code generates complex nodes they will
> > be rendered correctly.
> >
> >{ "foo" : {
> > "bar":[null],
> > "baz":[null]
> >   }
> >}
> >
> > This is what our server will generate if the internal representation
> > would be rendered in XML as you describe. This encoding can be
> > easily converted to XML.
>
> Yes, but we are talking about encoding anyxml instances as JSON strings
> containing well-formed XML - this is what Martin proposed in Yokohama, if I
> understood it correctly.
>
>


This string encoding is totally useless.
We will never implement it.  There is no way any client code is going to
double parse the string. (i.e. pass the string to an XML parser)

This is useful for WEB banners where the correct modeling tool is
(and always has been) a leaf.


And yes, I think we are wasting time. Seeking interoperability where there
> is none is useless. I propose this change to sec. 5.6 of the yang-json
> document:
>
> OLD
>An anyxml instance is encoded as a JSON name/value pair which MUST
>satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
>value can be an object, array, number, string or one of the literals
>"true", "false" and "null".
>
> NEW
>An anyxml instance is encoded as a JSON name/value pair which MUST
>satisfy I-JSON constraints.  The value can be an object, array, number,
>string or one of the literals "true", "false" and "null".
>
> This BTW also allows for strings containing XML.
>
>

IMO this is a bit more clear:
s/Otherwise it is/It is otherwise/

It was not clear before that otherwise is in addition to MUST.


> Lada
>
>

Andy


> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> >
> > >
> > >
> > > is not a well-formed XML document because it doesn't have a single
> document element.
> > >
> > >> This is news to me.  Maybe you mean it is a well-formed snippet
> > >> that may not be complete as an XML instance document.
> > >>
> > >> You cannot say "MUST do X, otherwise do Y".  This is incorrect
> > >> use of RFC 2119 terminology.  If MUST is used, that is the only
> option.
> > >
> > > OK, I will reformulate it.
> > >
> > >> You also need to explain exactly what interoperability is lost if the
> MUST
> > >> is not followed.  (e.g., mixed mode XML will not be translated
> properly to JSON).
> > >
> > > If the MUST isn't followed, then the interoperability problems that
> motivated I-JSON restrictions come into play. It has nothing to do with
> mixed XML content - translation between JSON and XML (and vice versa) in
> general cannot be guaranteed.
> > >
> > > Lada
> > >
> > >>
> > >>
> > >> Andy
> > >>
> > >>
> > >>
> > >> Lada
> > >>
> > >>>
> > >>> Rob
> > >>>
> > >>>
> > >>> On 16/11/2015 

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 18 Nov 2015, at 09:36, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Nov 18, 2015 at 08:03:02AM +0100, Ladislav Lhotka wrote:
>> 
>> 
>> And yes, I think we are wasting time. Seeking interoperability where there 
>> is none is useless. I propose this change to sec. 5.6 of the yang-json 
>> document:
>> 
>> OLD
>>   An anyxml instance is encoded as a JSON name/value pair which MUST
>>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
>>   value can be an object, array, number, string or one of the literals
>>   "true", "false" and "null".
>> 
>> NEW
>>   An anyxml instance is encoded as a JSON name/value pair which MUST
>>   satisfy I-JSON constraints.  The value can be an object, array, number,
>>   string or one of the literals "true", "false" and "null".
>> 
>> This BTW also allows for strings containing XML.
> 
> Lada,
> 
> what is the purpose of the second sentence? I checked RFC 7159 and it
> seems the proposed second sentence simply repeats the set of possible
> JSON values listed in section 3 of RFC 7159. So why is this sentence
> technically needed?

It's there to emphasize it can be any JSON value, because in one of the 
previous versions it was limited to an object. Maybe it's really not needed.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 18, 2015 at 08:03:02AM +0100, Ladislav Lhotka wrote:
> 
> 
> And yes, I think we are wasting time. Seeking interoperability where there is 
> none is useless. I propose this change to sec. 5.6 of the yang-json document:
> 
> OLD
>An anyxml instance is encoded as a JSON name/value pair which MUST
>satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
>value can be an object, array, number, string or one of the literals
>"true", "false" and "null".
> 
> NEW
>An anyxml instance is encoded as a JSON name/value pair which MUST
>satisfy I-JSON constraints.  The value can be an object, array, number,
>string or one of the literals "true", "false" and "null".
> 
> This BTW also allows for strings containing XML.

Lada,

what is the purpose of the second sentence? I checked RFC 7159 and it
seems the proposed second sentence simply repeats the set of possible
JSON values listed in section 3 of RFC 7159. So why is this sentence
technically needed?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 17 Nov 2015, at 11:19, Robert Wilton  wrote:
> 
> As a possible compromise, what about something like:
> 
> The JSON encoding defines that anyxml may be encoded in whatever way the 
> implementor finds useful, or even not at all.  If a preferred custom 
> encoding is not being used, then it is suggested that anyxml data be encoded 
> as a string containing XML to maximize legacy interoperability.

While this is quite complicated, I don't think it helps in any way. There are 
no anyxml objects that need to be encoded, so what an implementor finds useful 
is totally irrelevant. The yang-json spec should state what's permitted as the 
content of an anyxml instance in JSON encoding, and that's all. To this end, 
the current text is IMO sufficient, except that the "otherwise" part may be 
misleading - but it's not necessary.

Note that XML-in-JSON-string has its share of problems and may not be 
interoperable either: the content of an anyxml instance in XML encoding needn't 
be a well-formed XML document.

Lada

> 
> Rob
> 
> 
> On 16/11/2015 16:50, Andy Bierman wrote:
>> 
>> 
>> On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder 
>>  wrote:
>> On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
>> >
>> > YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
>> > I thought the whole point of the issue tracker was to prevent this sort
>> > of thing.   The rule should be "what new details have emerged that
>> > should cause us to change the previous decision?"
>> >
>> 
>> Andy, please note that this is a discussion primarily around the JSON
>> document and not around the YANG 1.1 document.
>> 
>> 
>> That doesn't mean we haven't discussed this issue for a long time already.
>> I thought we decided anyxml is not that interoperable and so we have
>> anydata that is supposedly interoperable.
>> 
>> So why try to constrain the JSON encoding?
>> For anyone sending mixed mode XML encoded as JSON,
>> they can get creative and do whatever they want.
>> 
>> 
>> For everybody else, anydata is simple enough to encode and decode.
>> 
>>  
>> /js
>> 
>> Andy
>>  
>> 
>> --
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> 
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka  wrote:

>
> > On 17 Nov 2015, at 11:19, Robert Wilton  wrote:
> >
> > As a possible compromise, what about something like:
> >
> > The JSON encoding defines that anyxml may be encoded in whatever way the
> implementor finds useful, or even not at all.  If a preferred custom
> encoding is not being used, then it is suggested that anyxml data be
> encoded as a string containing XML to maximize legacy interoperability.
>
> While this is quite complicated, I don't think it helps in any way. There
> are no anyxml objects that need to be encoded, so what an implementor finds
> useful is totally irrelevant. The yang-json spec should state what's
> permitted as the content of an anyxml instance in JSON encoding, and that's
> all. To this end, the current text is IMO sufficient, except that the
> "otherwise" part may be misleading - but it's not necessary.
>
> Note that XML-in-JSON-string has its share of problems and may not be
> interoperable either: the content of an anyxml instance in XML encoding
> needn't be a well-formed XML document.
>
>
So now anyxml includes XML that is not even well-formed?
This is news to me.  Maybe you mean it is a well-formed snippet
that may not be complete as an XML instance document.

You cannot say "MUST do X, otherwise do Y".  This is incorrect
use of RFC 2119 terminology.  If MUST is used, that is the only option.
You also need to explain exactly what interoperability is lost if the MUST
is not followed.  (e.g., mixed mode XML will not be translated properly to
JSON).


Andy



Lada
>
> >
> > Rob
> >
> >
> > On 16/11/2015 16:50, Andy Bierman wrote:
> >>
> >>
> >> On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >> On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> >> >
> >> > YANG 1.1 is going to take 2 more years if we slowly revisit every
> issue.
> >> > I thought the whole point of the issue tracker was to prevent this
> sort
> >> > of thing.   The rule should be "what new details have emerged that
> >> > should cause us to change the previous decision?"
> >> >
> >>
> >> Andy, please note that this is a discussion primarily around the JSON
> >> document and not around the YANG 1.1 document.
> >>
> >>
> >> That doesn't mean we haven't discussed this issue for a long time
> already.
> >> I thought we decided anyxml is not that interoperable and so we have
> >> anydata that is supposedly interoperable.
> >>
> >> So why try to constrain the JSON encoding?
> >> For anyone sending mixed mode XML encoded as JSON,
> >> they can get creative and do whatever they want.
> >>
> >>
> >> For everybody else, anydata is simple enough to encode and decode.
> >>
> >>
> >> /js
> >>
> >> Andy
> >>
> >>
> >> --
> >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103 
> >>
> >>
> >>
> >> ___
> >> netmod mailing list
> >>
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Randy Presuhn]

Hi -

> From: Robert Wilton
> Sent: Nov 17, 2015 2:19 AM
...
>As a possible compromise, what about something like:
>
>The JSON encoding defines that anyxml may be encoded in whatever way
>the implementor finds useful, or even not at all.  If a preferred
>custom encoding is not being used, then it is suggested that anyxml
>data be encoded as a string containing XML to maximize legacy
>interoperability.

For an "any" type to be conveyed with neither any indication of its
grammar nor of the encoding rules used to assemble that payload makes
me think that interoperability will only happen by lucky accident.

We've already established that it only requires a wave of a magic
wand for the recipient to know the *grammar* of the encoded data.
Is it going to take a second wave of another magic wand for the
recipient (or relay!) to guess what encoding rules have been used
for this value's payload?

Forgive the harsh words, but this seems truly and badly broken.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 17 Nov 2015, at 18:08, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka  wrote:
> 
> > On 17 Nov 2015, at 11:19, Robert Wilton  wrote:
> >
> > As a possible compromise, what about something like:
> >
> > The JSON encoding defines that anyxml may be encoded in whatever way the 
> > implementor finds useful, or even not at all.  If a preferred custom 
> > encoding is not being used, then it is suggested that anyxml data be 
> > encoded as a string containing XML to maximize legacy interoperability.
> 
> While this is quite complicated, I don't think it helps in any way. There are 
> no anyxml objects that need to be encoded, so what an implementor finds 
> useful is totally irrelevant. The yang-json spec should state what's 
> permitted as the content of an anyxml instance in JSON encoding, and that's 
> all. To this end, the current text is IMO sufficient, except that the 
> "otherwise" part may be misleading - but it's not necessary.
> 
> Note that XML-in-JSON-string has its share of problems and may not be 
> interoperable either: the content of an anyxml instance in XML encoding 
> needn't be a well-formed XML document.
> 
> 
> So now anyxml includes XML that is not even well-formed?

Sure. First, in the XML encoding the anyxml chunk may inherit namespace and 
entity declarations from the outer context. This could be corrected by adding 
these declarations to the JSON string. But then also, if we have

anyxml foo;

then this is a valid XML encoding


  
  


but the JSON string value

"foo": ""   

is not a well-formed XML document because it doesn't have a single document 
element.

> This is news to me.  Maybe you mean it is a well-formed snippet
> that may not be complete as an XML instance document.
> 
> You cannot say "MUST do X, otherwise do Y".  This is incorrect
> use of RFC 2119 terminology.  If MUST is used, that is the only option.

OK, I will reformulate it.

> You also need to explain exactly what interoperability is lost if the MUST
> is not followed.  (e.g., mixed mode XML will not be translated properly to 
> JSON).

If the MUST isn't followed, then the interoperability problems that motivated 
I-JSON restrictions come into play. It has nothing to do with mixed XML content 
- translation between JSON and XML (and vice versa) in general cannot be 
guaranteed.

Lada

> 
> 
> Andy
> 
> 
> 
> Lada
> 
> >
> > Rob
> >
> >
> > On 16/11/2015 16:50, Andy Bierman wrote:
> >>
> >>
> >> On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder 
> >>  wrote:
> >> On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> >> >
> >> > YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
> >> > I thought the whole point of the issue tracker was to prevent this sort
> >> > of thing.   The rule should be "what new details have emerged that
> >> > should cause us to change the previous decision?"
> >> >
> >>
> >> Andy, please note that this is a discussion primarily around the JSON
> >> document and not around the YANG 1.1 document.
> >>
> >>
> >> That doesn't mean we haven't discussed this issue for a long time already.
> >> I thought we decided anyxml is not that interoperable and so we have
> >> anydata that is supposedly interoperable.
> >>
> >> So why try to constrain the JSON encoding?
> >> For anyone sending mixed mode XML encoded as JSON,
> >> they can get creative and do whatever they want.
> >>
> >>
> >> For everybody else, anydata is simple enough to encode and decode.
> >>
> >>
> >> /js
> >>
> >> Andy
> >>
> >>
> >> --
> >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103 
> >>
> >>
> >>
> >> ___
> >> netmod mailing list
> >>
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Robert Wilton]

As a possible compromise, what about something like:

The JSON encoding defines that anyxml may be encoded in whatever way the 
implementor finds useful, or even not at all.  If a preferred custom 
encoding is not being used, then it is suggested that anyxml data be 
encoded as a string containing XML to maximize legacy interoperability.


Rob


On 16/11/2015 16:50, Andy Bierman wrote:



On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder 
> wrote:


On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
>
> YANG 1.1 is going to take 2 more years if we slowly revisit
every issue.
> I thought the whole point of the issue tracker was to prevent
this sort
> of thing.   The rule should be "what new details have emerged that
> should cause us to change the previous decision?"
>

Andy, please note that this is a discussion primarily around the JSON
document and not around the YANG 1.1 document.


That doesn't mean we haven't discussed this issue for a long time already.
I thought we decided anyxml is not that interoperable and so we have
anydata that is supposedly interoperable.

So why try to constrain the JSON encoding?
For anyone sending mixed mode XML encoded as JSON,
they can get creative and do whatever they want.


For everybody else, anydata is simple enough to encode and decode.

/js


Andy


--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Tue, Nov 17, 2015 at 12:11 PM, Ladislav Lhotka  wrote:

>
> > On 17 Nov 2015, at 21:03, Ladislav Lhotka  wrote:
> >
> >>
> >> On 17 Nov 2015, at 18:08, Andy Bierman  wrote:
> >>
> >>
> >>
> >> On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka  wrote:
> >>
> >>> On 17 Nov 2015, at 11:19, Robert Wilton  wrote:
> >>>
> >>> As a possible compromise, what about something like:
> >>>
> >>> The JSON encoding defines that anyxml may be encoded in whatever way
> the implementor finds useful, or even not at all.  If a preferred
>  custom encoding is not being used, then it is suggested that anyxml data
> be encoded as a string containing XML to maximize legacy interoperability.
> >>
> >> While this is quite complicated, I don't think it helps in any way.
> There are no anyxml objects that need to be encoded, so what an implementor
> finds useful is totally irrelevant. The yang-json spec should state what's
> permitted as the content of an anyxml instance in JSON encoding, and that's
> all. To this end, the current text is IMO sufficient, except that the
> "otherwise" part may be misleading - but it's not necessary.
> >>
> >> Note that XML-in-JSON-string has its share of problems and may not be
> interoperable either: the content of an anyxml instance in XML encoding
> needn't be a well-formed XML document.
> >>
> >>
> >> So now anyxml includes XML that is not even well-formed?
> >
> > Sure. First, in the XML encoding the anyxml chunk may inherit namespace
> and entity declarations from the outer context. This could be corrected by
> adding these declarations to the JSON string. But then also, if we have
> >
> > anyxml foo;
> >
> > then this is a valid XML encoding
> >
> > 
> >  
> >  
> > 
> >
>


(!) The internal representation of data is implementation-specific.



> > but the JSON string value
> >
> > "foo": ""
>
> Sorry, this was supposed to be
>
> "foo" : ""
>
>

If the internal server code generates complex nodes they will
be rendered correctly.

   { "foo" : {
"bar":[null],
"baz":[null]
  }
   }

This is what our server will generate if the internal representation
would be rendered in XML as you describe. This encoding can be
easily converted to XML.




> Lada
>


Andy



>
> >
> >
> > is not a well-formed XML document because it doesn't have a single
> document element.
> >
> >> This is news to me.  Maybe you mean it is a well-formed snippet
> >> that may not be complete as an XML instance document.
> >>
> >> You cannot say "MUST do X, otherwise do Y".  This is incorrect
> >> use of RFC 2119 terminology.  If MUST is used, that is the only option.
> >
> > OK, I will reformulate it.
> >
> >> You also need to explain exactly what interoperability is lost if the
> MUST
> >> is not followed.  (e.g., mixed mode XML will not be translated properly
> to JSON).
> >
> > If the MUST isn't followed, then the interoperability problems that
> motivated I-JSON restrictions come into play. It has nothing to do with
> mixed XML content - translation between JSON and XML (and vice versa) in
> general cannot be guaranteed.
> >
> > Lada
> >
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >> Lada
> >>
> >>>
> >>> Rob
> >>>
> >>>
> >>> On 16/11/2015 16:50, Andy Bierman wrote:
> 
> 
>  On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>  On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> >
> > YANG 1.1 is going to take 2 more years if we slowly revisit every
> issue.
> > I thought the whole point of the issue tracker was to prevent this
> sort
> > of thing.   The rule should be "what new details have emerged that
> > should cause us to change the previous decision?"
> >
> 
>  Andy, please note that this is a discussion primarily around the JSON
>  document and not around the YANG 1.1 document.
> 
> 
>  That doesn't mean we haven't discussed this issue for a long time
> already.
>  I thought we decided anyxml is not that interoperable and so we have
>  anydata that is supposedly interoperable.
> 
>  So why try to constrain the JSON encoding?
>  For anyone sending mixed mode XML encoded as JSON,
>  they can get creative and do whatever they want.
> 
> 
>  For everybody else, anydata is simple enough to encode and decode.
> 
> 
>  /js
> 
>  Andy
> 
> 
>  --
>  Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>  Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>  Fax:   +49 421 200 3103 
> 
> 
> 
>  ___
>  netmod mailing list
> 
>  netmod@ietf.org
>  https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 17 Nov 2015, at 21:18, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Nov 17, 2015 at 12:11 PM, Ladislav Lhotka  wrote:
> 
> > On 17 Nov 2015, at 21:03, Ladislav Lhotka  wrote:
> >
> >>
> >> On 17 Nov 2015, at 18:08, Andy Bierman  wrote:
> >>
> >>
> >>
> >> On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka  wrote:
> >>
> >>> On 17 Nov 2015, at 11:19, Robert Wilton  wrote:
> >>>
> >>> As a possible compromise, what about something like:
> >>>
> >>> The JSON encoding defines that anyxml may be encoded in whatever way the 
> >>> implementor finds useful, or even not at all.  If a preferred custom 
> >>> encoding is not being used, then it is suggested that anyxml data be 
> >>> encoded as a string containing XML to maximize legacy interoperability.
> >>
> >> While this is quite complicated, I don't think it helps in any way. There 
> >> are no anyxml objects that need to be encoded, so what an implementor 
> >> finds useful is totally irrelevant. The yang-json spec should state what's 
> >> permitted as the content of an anyxml instance in JSON encoding, and 
> >> that's all. To this end, the current text is IMO sufficient, except that 
> >> the "otherwise" part may be misleading - but it's not necessary.
> >>
> >> Note that XML-in-JSON-string has its share of problems and may not be 
> >> interoperable either: the content of an anyxml instance in XML encoding 
> >> needn't be a well-formed XML document.
> >>
> >>
> >> So now anyxml includes XML that is not even well-formed?
> >
> > Sure. First, in the XML encoding the anyxml chunk may inherit namespace and 
> > entity declarations from the outer context. This could be corrected by 
> > adding these declarations to the JSON string. But then also, if we have
> >
> > anyxml foo;
> >
> > then this is a valid XML encoding
> >
> > 
> >  
> >  
> > 
> >
> 
> 
> (!) The internal representation of data is implementation-specific.
> 
>  
> > but the JSON string value
> >
> > "foo": ""
> 
> Sorry, this was supposed to be
> 
> "foo" : ""
> 
> 
> 
> If the internal server code generates complex nodes they will
> be rendered correctly.
> 
>{ "foo" : {
> "bar":[null],
> "baz":[null]
>   }
>}
> 
> This is what our server will generate if the internal representation
> would be rendered in XML as you describe. This encoding can be
> easily converted to XML.

Yes, but we are talking about encoding anyxml instances as JSON strings 
containing well-formed XML - this is what Martin proposed in Yokohama, if I 
understood it correctly.

And yes, I think we are wasting time. Seeking interoperability where there is 
none is useless. I propose this change to sec. 5.6 of the yang-json document:

OLD
   An anyxml instance is encoded as a JSON name/value pair which MUST
   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
   value can be an object, array, number, string or one of the literals
   "true", "false" and "null".

NEW
   An anyxml instance is encoded as a JSON name/value pair which MUST
   satisfy I-JSON constraints.  The value can be an object, array, number,
   string or one of the literals "true", "false" and "null".

This BTW also allows for strings containing XML.

Lada

> 
> 
>  
> Lada
> 
> 
> Andy
> 
>  
> 
> >
> >
> > is not a well-formed XML document because it doesn't have a single document 
> > element.
> >
> >> This is news to me.  Maybe you mean it is a well-formed snippet
> >> that may not be complete as an XML instance document.
> >>
> >> You cannot say "MUST do X, otherwise do Y".  This is incorrect
> >> use of RFC 2119 terminology.  If MUST is used, that is the only option.
> >
> > OK, I will reformulate it.
> >
> >> You also need to explain exactly what interoperability is lost if the MUST
> >> is not followed.  (e.g., mixed mode XML will not be translated properly to 
> >> JSON).
> >
> > If the MUST isn't followed, then the interoperability problems that 
> > motivated I-JSON restrictions come into play. It has nothing to do with 
> > mixed XML content - translation between JSON and XML (and vice versa) in 
> > general cannot be guaranteed.
> >
> > Lada
> >
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >> Lada
> >>
> >>>
> >>> Rob
> >>>
> >>>
> >>> On 16/11/2015 16:50, Andy Bierman wrote:
> 
> 
>  On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder 
>   wrote:
>  On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> >
> > YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
> > I thought the whole point of the issue tracker was to prevent this sort
> > of thing.   The rule should be "what new details have emerged that
> > should cause us to change the previous decision?"
> >
> 
>  Andy, please note that this is a discussion primarily around the JSON
>  document and not around the YANG 1.1 

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> >
> > YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
> > I thought the whole point of the issue tracker was to prevent this sort
> > of thing.   The rule should be "what new details have emerged that
> > should cause us to change the previous decision?"
> >
>
> Andy, please note that this is a discussion primarily around the JSON
> document and not around the YANG 1.1 document.
>
>
That doesn't mean we haven't discussed this issue for a long time already.
I thought we decided anyxml is not that interoperable and so we have
anydata that is supposedly interoperable.

So why try to constrain the JSON encoding?
For anyone sending mixed mode XML encoded as JSON,
they can get creative and do whatever they want.


For everybody else, anydata is simple enough to encode and decode.



> /js
>

Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 16 Nov 2015, at 14:40, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Nov 16, 2015 at 01:09:20PM +0100, Ladislav Lhotka wrote:
>> 
>>> On 16 Nov 2015, at 12:55, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
 
 YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
 I thought the whole point of the issue tracker was to prevent this sort
 of thing.   The rule should be "what new details have emerged that
 should cause us to change the previous decision?"
 
>>> 
>>> Andy, please note that this is a discussion primarily around the JSON
>>> document and not around the YANG 1.1 document.
>> 
>> Except that it might be useful to clarify in 6020bis whether "anyxml" really 
>> means
>> 
>> 1. specifically "any XML", or
>> 
>> 2. schema-less data in any supported encoding.
>> 
>> If it is #1, then arguably c/e are not acceptable options for the JSON 
>> encoding. I prefer #2.
>> 
> 
> I believe the outcome of the discussion is that anyxml means any XML.

I don't think there has been any clear consensus so far, I understand you and 
Martin support b) while Andy and I voted for c/e).

> There also was clear agreement to not change the definition of anyxml.

OK, using the same logic, sections that talk about NETCONF and edit-config 
(such as 7.9.6) don't apply to other protocols and their operations. If we can 
agree on this as a general principle, i.e. not to do any extrapolations of the 
6020bis text, I am prepared to accept alternative b) for JSON ancoding of 
anyxml, but I'd like to ask those who support it to propose a concrete wording.

Thanks, Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Mon, Nov 16, 2015 at 01:09:20PM +0100, Ladislav Lhotka wrote:
> 
> > On 16 Nov 2015, at 12:55, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> >> 
> >> YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
> >> I thought the whole point of the issue tracker was to prevent this sort
> >> of thing.   The rule should be "what new details have emerged that
> >> should cause us to change the previous decision?"
> >> 
> > 
> > Andy, please note that this is a discussion primarily around the JSON
> > document and not around the YANG 1.1 document.
> 
> Except that it might be useful to clarify in 6020bis whether "anyxml" really 
> means
> 
> 1. specifically "any XML", or
> 
> 2. schema-less data in any supported encoding.
> 
> If it is #1, then arguably c/e are not acceptable options for the JSON 
> encoding. I prefer #2.
>

I believe the outcome of the discussion is that anyxml means any XML.
There also was clear agreement to not change the definition of anyxml.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
> 
> YANG 1.1 is going to take 2 more years if we slowly revisit every issue.
> I thought the whole point of the issue tracker was to prevent this sort
> of thing.   The rule should be "what new details have emerged that
> should cause us to change the previous decision?"
>

Andy, please note that this is a discussion primarily around the JSON
document and not around the YANG 1.1 document.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 13 Nov 2015, at 19:19, Andy Bierman  wrote:
> 
> 
> 
> On Wed, Nov 11, 2015 at 11:51 PM, Juergen Schoenwaelder 
>  wrote:
> On Thu, Nov 12, 2015 at 08:10:51AM +0100, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> >
> > > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> > >>
> > >> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder 
> > >> >  wrote:
> > >> >
> > >> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > >> >>
> > >> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder 
> > >> >>>  wrote:
> > >> >>>
> > >> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > >> 
> > >> >
> > >> > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > >> >
> > >> > Since the use of anyxml limits the manipulation of the content, it 
> > >> > is
> > >> > RECOMMENDED that the "anyxml" statement not be used to define
> > >> > configuration data.
> > >> >
> > >> > It should be noted that in YANG version 1, anyxml was the only
> > >> > statement that could model an unknown hierarchy of data.  In many
> > >> > cases this unknown hierarchy of data is actually modelled in YANG,
> > >> > but the exact YANG model is not known at design time.  In these
> > >> > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > >> > of anyxml.
> > >> 
> > >>  The first paragraph is for config data and the second for data that 
> > >>  can modelled with YANG. If we want to deprecate "anyxml" for use 
> > >>  with data that are neither of these, 6020bis should say so. I'd be 
> > >>  fine with that.
> > >> 
> > >> >>>
> > >> >>> The guidelines will say that any usage of anyxml in the IETF will be
> > >> >>> carefully checked by YANG doctors. See Y34 for all details.
> > >> >>>
> > >> > There is more text in Y34-05 that will go into the guidelines. I 
> > >> > call
> > >> > this "effectively deprecated", you can call it differently if you
> > >> > want. Frankly, this thread is about how to encode anyxml in JSON 
> > >> > not
> > >> > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is 
> > >> > what
> > >> > we ended up with.
> > >> 
> > >>  I am strongly against encoding serialized XML as JSON strings. It 
> > >>  is IMO totally useless and the spec would have to deal with awkward 
> > >>  complications because it is not true that arbitrary XML-encoded 
> > >>  anyxml content can be used without changes in JSON encoding.
> > >> 
> > >>  Perhaps the best solution would be to state that JSON encoding is 
> > >>  incompatible with data models that use "anyxml".
> > >> 
> > >> >>>
> > >> >>> Perhaps we can only settle this by doing an opinion poll since
> > >> >>> debating this forever is not useful. So what are the options?
> > >> >>>
> > >> >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> > >> >>>  you use anyxml in a data model, the content will not appear in JSON
> > >> >>>  encodings.
> > >> >>>
> > >> >>> b) The JSON encoding defines that anyxml data is encoded as a string
> > >> >>>  containing XML.
> > >> >>>
> > >> >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> > >> >>>  the implementor finds useful.
> > >> >>>
> > >> >>> d) If the anyxml content is actually valid anydata content, encode it
> > >> >>>  using anydata rules. Content that is not valid anydata content is
> > >> >>>  not encoded at all.
> > >> >>>
> > >> >>> Any options missing?
> > >> >>
> > >> >> Yes, the one that's in yang-json-06:
> > >> >>
> > >> >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> > >> >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> > >> >>   value can be an object, array, number, string or one of the literals
> > >> >>   "true", "false" and "null".
> > >> >>
> > >> >> My preference is e), and then a).
> > >> >>
> > >> >
> > >> > Is e) not the same as c)? I assume that the JSON encoding will always
> > >> > be valid JSON (or I-JSON to be precise). So it seems the only 
> > >> > refinement
> > >> > of e) is the toplevel.
> > >>
> > >> c) sounds like the same data can be encoded in different ways depending 
> > >> on what the implementor finds useful, e.g. encode all numbers as strings.
> > >>
> > >
> > > But e) says the same, I fail to see the difference here.
> >
> > The way how c) is formulated is rather suggestive: beware, this is
> > non-interoperable by its very nature. I think it is as interoperable as
> > anyxml in XML encoding. Without knowing the context, translating anyxml
> > chunks from XML to JSON, and vice versa, is quite problematic even for
> > b).
> 
> e) is no better than c) in terms of 

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Sat, Nov 14, 2015 at 1:27 AM, Ladislav Lhotka  wrote:

>
> > On 13 Nov 2015, at 19:19, Andy Bierman  wrote:
> >
> >
> >
> > On Wed, Nov 11, 2015 at 11:51 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > On Thu, Nov 12, 2015 at 08:10:51AM +0100, Ladislav Lhotka wrote:
> > > Juergen Schoenwaelder  writes:
> > >
> > > > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> > > >>
> > > >> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > > >> >
> > > >> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > > >> >>
> > > >> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > > >> >>>
> > > >> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > > >> 
> > > >> >
> > > >> > I wrote 'effectively deprecated' and here is the text in
> 6020bis.
> > > >> >
> > > >> > Since the use of anyxml limits the manipulation of the
> content, it is
> > > >> > RECOMMENDED that the "anyxml" statement not be used to define
> > > >> > configuration data.
> > > >> >
> > > >> > It should be noted that in YANG version 1, anyxml was the only
> > > >> > statement that could model an unknown hierarchy of data.  In
> many
> > > >> > cases this unknown hierarchy of data is actually modelled in
> YANG,
> > > >> > but the exact YANG model is not known at design time.  In
> these
> > > >> > situations, it is RECOMMENDED to use anydata (Section 7.10)
> instead
> > > >> > of anyxml.
> > > >> 
> > > >>  The first paragraph is for config data and the second for data
> that can modelled with YANG. If we want to deprecate "anyxml" for use with
> data that are neither of these, 6020bis should say so. I'd be fine with
> that.
> > > >> 
> > > >> >>>
> > > >> >>> The guidelines will say that any usage of anyxml in the IETF
> will be
> > > >> >>> carefully checked by YANG doctors. See Y34 for all details.
> > > >> >>>
> > > >> > There is more text in Y34-05 that will go into the
> guidelines. I call
> > > >> > this "effectively deprecated", you can call it differently if
> you
> > > >> > want. Frankly, this thread is about how to encode anyxml in
> JSON not
> > > >> > about the YANG 1.1 issue Y34. You may not like Y34-05 but
> this is what
> > > >> > we ended up with.
> > > >> 
> > > >>  I am strongly against encoding serialized XML as JSON strings.
> It is IMO totally useless and the spec would have to deal with awkward
> complications because it is not true that arbitrary XML-encoded anyxml
> content can be used without changes in JSON encoding.
> > > >> 
> > > >>  Perhaps the best solution would be to state that JSON encoding
> is incompatible with data models that use "anyxml".
> > > >> 
> > > >> >>>
> > > >> >>> Perhaps we can only settle this by doing an opinion poll since
> > > >> >>> debating this forever is not useful. So what are the options?
> > > >> >>>
> > > >> >>> a) The JSON encoding does not define anyxml is not encoded at
> all. If
> > > >> >>>  you use anyxml in a data model, the content will not appear in
> JSON
> > > >> >>>  encodings.
> > > >> >>>
> > > >> >>> b) The JSON encoding defines that anyxml data is encoded as a
> string
> > > >> >>>  containing XML.
> > > >> >>>
> > > >> >>> c) The JSON encoding defines that anyxml is encoded in whatever
> way
> > > >> >>>  the implementor finds useful.
> > > >> >>>
> > > >> >>> d) If the anyxml content is actually valid anydata content,
> encode it
> > > >> >>>  using anydata rules. Content that is not valid anydata content
> is
> > > >> >>>  not encoded at all.
> > > >> >>>
> > > >> >>> Any options missing?
> > > >> >>
> > > >> >> Yes, the one that's in yang-json-06:
> > > >> >>
> > > >> >> e) An anyxml instance is encoded as a JSON name/value pair which
> MUST
> > > >> >>   satisfy I-JSON constraints.  Otherwise it is unrestricted,
> i.e., the
> > > >> >>   value can be an object, array, number, string or one of the
> literals
> > > >> >>   "true", "false" and "null".
> > > >> >>
> > > >> >> My preference is e), and then a).
> > > >> >>
> > > >> >
> > > >> > Is e) not the same as c)? I assume that the JSON encoding will
> always
> > > >> > be valid JSON (or I-JSON to be precise). So it seems the only
> refinement
> > > >> > of e) is the toplevel.
> > > >>
> > > >> c) sounds like the same data can be encoded in different ways
> depending on what the implementor finds useful, e.g. encode all numbers as
> strings.
> > > >>
> > > >
> > > > But e) says the same, I fail to see the difference here.
> > >
> > > The way how c) is formulated is rather suggestive: beware, this is
> > > non-interoperable by its very nature. I think it is as interoperable as
> > > anyxml in XML encoding. Without knowing the context, translating anyxml

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Wed, Nov 11, 2015 at 11:51 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Nov 12, 2015 at 08:10:51AM +0100, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> >
> > > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> > >>
> > >> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >> >
> > >> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > >> >>
> > >> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >> >>>
> > >> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > >> 
> > >> >
> > >> > I wrote 'effectively deprecated' and here is the text in
> 6020bis.
> > >> >
> > >> > Since the use of anyxml limits the manipulation of the content,
> it is
> > >> > RECOMMENDED that the "anyxml" statement not be used to define
> > >> > configuration data.
> > >> >
> > >> > It should be noted that in YANG version 1, anyxml was the only
> > >> > statement that could model an unknown hierarchy of data.  In
> many
> > >> > cases this unknown hierarchy of data is actually modelled in
> YANG,
> > >> > but the exact YANG model is not known at design time.  In these
> > >> > situations, it is RECOMMENDED to use anydata (Section 7.10)
> instead
> > >> > of anyxml.
> > >> 
> > >>  The first paragraph is for config data and the second for data
> that can modelled with YANG. If we want to deprecate "anyxml" for use with
> data that are neither of these, 6020bis should say so. I'd be fine with
> that.
> > >> 
> > >> >>>
> > >> >>> The guidelines will say that any usage of anyxml in the IETF will
> be
> > >> >>> carefully checked by YANG doctors. See Y34 for all details.
> > >> >>>
> > >> > There is more text in Y34-05 that will go into the guidelines.
> I call
> > >> > this "effectively deprecated", you can call it differently if
> you
> > >> > want. Frankly, this thread is about how to encode anyxml in
> JSON not
> > >> > about the YANG 1.1 issue Y34. You may not like Y34-05 but this
> is what
> > >> > we ended up with.
> > >> 
> > >>  I am strongly against encoding serialized XML as JSON strings.
> It is IMO totally useless and the spec would have to deal with awkward
> complications because it is not true that arbitrary XML-encoded anyxml
> content can be used without changes in JSON encoding.
> > >> 
> > >>  Perhaps the best solution would be to state that JSON encoding
> is incompatible with data models that use "anyxml".
> > >> 
> > >> >>>
> > >> >>> Perhaps we can only settle this by doing an opinion poll since
> > >> >>> debating this forever is not useful. So what are the options?
> > >> >>>
> > >> >>> a) The JSON encoding does not define anyxml is not encoded at
> all. If
> > >> >>>  you use anyxml in a data model, the content will not appear in
> JSON
> > >> >>>  encodings.
> > >> >>>
> > >> >>> b) The JSON encoding defines that anyxml data is encoded as a
> string
> > >> >>>  containing XML.
> > >> >>>
> > >> >>> c) The JSON encoding defines that anyxml is encoded in whatever
> way
> > >> >>>  the implementor finds useful.
> > >> >>>
> > >> >>> d) If the anyxml content is actually valid anydata content,
> encode it
> > >> >>>  using anydata rules. Content that is not valid anydata content is
> > >> >>>  not encoded at all.
> > >> >>>
> > >> >>> Any options missing?
> > >> >>
> > >> >> Yes, the one that's in yang-json-06:
> > >> >>
> > >> >> e) An anyxml instance is encoded as a JSON name/value pair which
> MUST
> > >> >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e.,
> the
> > >> >>   value can be an object, array, number, string or one of the
> literals
> > >> >>   "true", "false" and "null".
> > >> >>
> > >> >> My preference is e), and then a).
> > >> >>
> > >> >
> > >> > Is e) not the same as c)? I assume that the JSON encoding will
> always
> > >> > be valid JSON (or I-JSON to be precise). So it seems the only
> refinement
> > >> > of e) is the toplevel.
> > >>
> > >> c) sounds like the same data can be encoded in different ways
> depending on what the implementor finds useful, e.g. encode all numbers as
> strings.
> > >>
> > >
> > > But e) says the same, I fail to see the difference here.
> >
> > The way how c) is formulated is rather suggestive: beware, this is
> > non-interoperable by its very nature. I think it is as interoperable as
> > anyxml in XML encoding. Without knowing the context, translating anyxml
> > chunks from XML to JSON, and vice versa, is quite problematic even for
> > b).
>
> e) is no better than c) in terms of interoperability
>
>

(e) does not even make sense. "Otherwise" is never paired with "MUST".

Interoperability expectations should be very low for anyxml.
We already established that over 1000 emails ago.


/js
>

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Andy Bierman  wrote:
>> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
>> 
>> > Hello,
>> >
>> > I am not favor of it, either, but RFC6020 is here and is being widely
>> > deployed. So is RESTCONF+JSON, which is favored by application developers
>> > in the field today, as is NETCONF devices producing anyxml. We do need a
>> > reasonable way of bridging the two -- no matter whether it is configuration
>> > or operational data.
>> >
>> >
>> 
>> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
>> I do not agree that all the "extra XML bits" that are causing so much
>> concern
>> are ever saved in a datastore.  Martin says we need anyxml for RPC input
>> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
>> operation depends on anything except elements and attributes.
>
> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> supposedly data modeling language agnostic.
>
> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> if we ever do a new version of NETCONF, we use anydata instead.

The simplest solution in this case would be to use a standard XML schema
language - XSD or RELAX NG.

Lada

>
>
> /martin
>
>
>
>> If the JSON looks like a leaf, then no tool is going to analyse the string
>> to see if it a well-formed XML instance document, so it can be re-parsed.
>> Unless a JSON array or object is started, the tool will not
>> think it is dealing with any child nodes.
>> 
>> There are lots of things that NETCONF can do that are trimmed out of
>> RESTCONF.
>> JSON representation or raw XML seems really low priority to me.
>> Are there any use-cases? What processing instructions, character entities,
>> etc.
>> are being used in the wild already?  None? Don't we have enough real
>> problems to
>> solve without rat-holing over corner-cases all the time?
>> 
>> 
>> Andy
>> 
>> 
>> 
>> 
>> > At any rate, a simple string is not going to cut it, as it does not retain
>> > modeling context nor encoding details of the data being transported --
>> > rendering reliable automated translation impossible.
>> >
>> > Bye,
>> > Robert
>> >
>> > On 11/10/2015 03:19 AM, Andy Bierman wrote:
>> >
>> > Hi,
>> >
>> > I am not in favor of anything XML or JSON specific in YANG.
>> > In reality, nobody uses anyxml as a configuration data node,
>> > so an improper roundtrip translation from JSON to XML
>> > is not going to happen.
>> >
>> > Encoding anyxml as a string is not going to happen either.
>> > Not sure what the difference between 'anyxml' and 'type string'
>> > is at that point.
>> >
>> > Why does YANG even need a special type of leaf that is a blob of XML?
>> > Can't a single-quoted string serve that purpose?
>> >
>> >
>> > Andy
>> >
>> >
>> > On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga < n...@hq.sk>
>> > wrote:
>> >
>> >> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>> >>
>> >>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>>  >anyxml as a string that has XML inside makes sense.
>> 
>> >>> The possibility of sending arbitrary (non-YANG) data in the native
>> >>> encoding can occassionally be useful, and even more so in JSON. For
>> >>> example, I have to work with a JSON-based format for specifying DNSSEC
>> >>> signing policies. While my plan is to eventually replace this format with
>> >>> YANG-modelled data, it would help me, as an interim solution, to simply
>> >>> send the data in the legacy format. That's why I want to retain the
>> >>> existing rules for JSON encoding of anyxml, unless something else is
>> >>> available. Sending XML documents as strings is still possible although 
>> >>> IMO
>> >>> next to useless.
>> >>>
>> >>
>> >> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies
>> >> non-transparent in case the sender (a NETCONF NE) and receiver (an 
>> >> RESTCONF
>> >> application) have out-of-band knowledge of the data being sent over 
>> >> anyxml.
>> >> Given the proxy does not have this knowledge, it cannot reliably deal with
>> >> lists, as they lack a container element in XML encoding.
>> >>
>> >> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as
>> >> a separate well-known attribute?
>> >>
>> >> Bye,
>> >> Robert
>> >>
>> >> ___
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>> >
>> >
>> >
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

Robert Varga  writes:

> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>>> >anyxml as a string that has XML inside makes sense.
>> The possibility of sending arbitrary (non-YANG) data in the native encoding 
>> can occassionally be useful, and even more so in JSON. For example, I have 
>> to work with a JSON-based format for specifying DNSSEC signing policies. 
>> While my plan is to eventually replace this format with YANG-modelled data, 
>> it would help me, as an interim solution, to simply send the data in the 
>> legacy format. That's why I want to retain the existing rules for JSON 
>> encoding of anyxml, unless something else is available. Sending XML 
>> documents as strings is still possible although IMO next to useless.
>
> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies 
> non-transparent in case the sender (a NETCONF NE) and receiver (an 
> RESTCONF application) have out-of-band knowledge of the data being sent 
> over anyxml. Given the proxy does not have this knowledge, it cannot 
> reliably deal with lists, as they lack a container element in XML
> encoding.

My view of anyxml is that it is a "controlled loophole" that allows
arbitrary non-YANG stuff to be sent. The only requirement is that it
won't break the syntax of the document in which it is embedded - and
this of course depends on the encoding used. It should be used scarcely,
and yes, it generally isn't interoperable and
encoding-transparent. Whenever it is needed, the implementations should
deal with these issues on an ad hoc basis.

So far it has mostly been used in specifications (NETCONF, yang-patch,
zerotouch), i.e. outside the network management context, where YANG
serves as an encoding-independent schema language.

I think it *may* occassionally be useful but it is also true that it can
always be substituted with a string or binary leaf. The only advantage of
sending such data in the "native" encoding is that it can be parsed in
one go.

>
> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as 
> a separate well-known attribute?

I don't think this could be useful because I believe such schema-less
chunks really make sense only if their encoding is the same as that of
the outer document.

Lada

>
> Bye,
> Robert

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 11:54:58AM +0100, Ladislav Lhotka wrote:
> 
> > On 11 Nov 2015, at 09:07, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
> >> Andy Bierman  wrote:
> >>> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> >>> 
>  Hello,
>  
>  I am not favor of it, either, but RFC6020 is here and is being widely
>  deployed. So is RESTCONF+JSON, which is favored by application developers
>  in the field today, as is NETCONF devices producing anyxml. We do need a
>  reasonable way of bridging the two -- no matter whether it is 
>  configuration
>  or operational data.
>  
>  
> >>> 
> >>> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> >>> I do not agree that all the "extra XML bits" that are causing so much
> >>> concern
> >>> are ever saved in a datastore.  Martin says we need anyxml for RPC input
> >>> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> >>> operation depends on anything except elements and attributes.
> >> 
> >> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> >> supposedly data modeling language agnostic.
> >> 
> >> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> >> if we ever do a new version of NETCONF, we use anydata instead.
> >> 
> > 
> > We are effectively deprecating anyxml in YANG 1.1. We have reached
> > agreement on Y34-05 and I do not see any new arguments popping up.
> 
> There is nothing in 6020bis indicating that "anyxml" is being deprecated.
>

I wrote 'effectively deprecated' and here is the text in 6020bis.

   Since the use of anyxml limits the manipulation of the content, it is
   RECOMMENDED that the "anyxml" statement not be used to define
   configuration data.

   It should be noted that in YANG version 1, anyxml was the only
   statement that could model an unknown hierarchy of data.  In many
   cases this unknown hierarchy of data is actually modelled in YANG,
   but the exact YANG model is not known at design time.  In these
   situations, it is RECOMMENDED to use anydata (Section 7.10) instead
   of anyxml.

There is more text in Y34-05 that will go into the guidelines. I call
this "effectively deprecated", you can call it differently if you
want. Frankly, this thread is about how to encode anyxml in JSON not
about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
we ended up with.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 08:31:14AM -0800, Andy Bierman wrote:
> On Wed, Nov 11, 2015 at 7:32 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> > >
> > > > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > > >>
> > > >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> > > >>>
> > > >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > > 
> > > >
> > > > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > > >
> > > > Since the use of anyxml limits the manipulation of the content, it
> > is
> > > > RECOMMENDED that the "anyxml" statement not be used to define
> > > > configuration data.
> > > >
> > > > It should be noted that in YANG version 1, anyxml was the only
> > > > statement that could model an unknown hierarchy of data.  In many
> > > > cases this unknown hierarchy of data is actually modelled in YANG,
> > > > but the exact YANG model is not known at design time.  In these
> > > > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > > > of anyxml.
> > > 
> > >  The first paragraph is for config data and the second for data that
> > can modelled with YANG. If we want to deprecate "anyxml" for use with data
> > that are neither of these, 6020bis should say so. I'd be fine with that.
> > > 
> > > >>>
> > > >>> The guidelines will say that any usage of anyxml in the IETF will be
> > > >>> carefully checked by YANG doctors. See Y34 for all details.
> > > >>>
> > > > There is more text in Y34-05 that will go into the guidelines. I
> > call
> > > > this "effectively deprecated", you can call it differently if you
> > > > want. Frankly, this thread is about how to encode anyxml in JSON
> > not
> > > > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is
> > what
> > > > we ended up with.
> > > 
> > >  I am strongly against encoding serialized XML as JSON strings. It
> > is IMO totally useless and the spec would have to deal with awkward
> > complications because it is not true that arbitrary XML-encoded anyxml
> > content can be used without changes in JSON encoding.
> > > 
> > >  Perhaps the best solution would be to state that JSON encoding is
> > incompatible with data models that use "anyxml".
> > > 
> > > >>>
> > > >>> Perhaps we can only settle this by doing an opinion poll since
> > > >>> debating this forever is not useful. So what are the options?
> > > >>>
> > > >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> > > >>>  you use anyxml in a data model, the content will not appear in JSON
> > > >>>  encodings.
> > > >>>
> > > >>> b) The JSON encoding defines that anyxml data is encoded as a string
> > > >>>  containing XML.
> > > >>>
> > > >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> > > >>>  the implementor finds useful.
> > > >>>
> > > >>> d) If the anyxml content is actually valid anydata content, encode it
> > > >>>  using anydata rules. Content that is not valid anydata content is
> > > >>>  not encoded at all.
> > > >>>
> > > >>> Any options missing?
> > > >>
> > > >> Yes, the one that's in yang-json-06:
> > > >>
> > > >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> > > >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> > > >>   value can be an object, array, number, string or one of the literals
> > > >>   "true", "false" and "null".
> > > >>
> > > >> My preference is e), and then a).
> > > >>
> > > >
> > > > Is e) not the same as c)? I assume that the JSON encoding will always
> > > > be valid JSON (or I-JSON to be precise). So it seems the only
> > refinement
> > > > of e) is the toplevel.
> > >
> > > c) sounds like the same data can be encoded in different ways depending
> > on what the implementor finds useful, e.g. encode all numbers as strings.
> > >
> >
> > But e) says the same, I fail to see the difference here.
> >
> >
> IMO the only option is (f)
> 
>  f) If the anyxml content is actually valid anydata content, encode it
> using anydata rules. Content that is not valid anydata content is
> either not encoded at all, or encoded in an implementation-specific
> manner

This is essentially the same as d).

> Nobody has answered my question about the "WEB banner" type of object.
> The only reports we have ever heard on this sort of object indicate that
> a leaf is used, NOT ANYXML!  Nobody seems to be using anyxml to store WEB
> page snippets in their configuration.  Clearly a leaf is interoperable for
> both XML and JSON, plus NETCONF or RESTCONF.  But we keep insisting
> the YANG to JSON mapping needs to support this 

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> 
> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> >> 
> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder 
> >>>  wrote:
> >>> 
> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
>  
> > 
> > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > 
> > Since the use of anyxml limits the manipulation of the content, it is
> > RECOMMENDED that the "anyxml" statement not be used to define
> > configuration data.
> > 
> > It should be noted that in YANG version 1, anyxml was the only
> > statement that could model an unknown hierarchy of data.  In many
> > cases this unknown hierarchy of data is actually modelled in YANG,
> > but the exact YANG model is not known at design time.  In these
> > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > of anyxml.
>  
>  The first paragraph is for config data and the second for data that can 
>  modelled with YANG. If we want to deprecate "anyxml" for use with data 
>  that are neither of these, 6020bis should say so. I'd be fine with that.
>  
> >>> 
> >>> The guidelines will say that any usage of anyxml in the IETF will be
> >>> carefully checked by YANG doctors. See Y34 for all details.
> >>> 
> > There is more text in Y34-05 that will go into the guidelines. I call
> > this "effectively deprecated", you can call it differently if you
> > want. Frankly, this thread is about how to encode anyxml in JSON not
> > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
> > we ended up with.
>  
>  I am strongly against encoding serialized XML as JSON strings. It is IMO 
>  totally useless and the spec would have to deal with awkward 
>  complications because it is not true that arbitrary XML-encoded anyxml 
>  content can be used without changes in JSON encoding. 
>  
>  Perhaps the best solution would be to state that JSON encoding is 
>  incompatible with data models that use "anyxml".
>  
> >>> 
> >>> Perhaps we can only settle this by doing an opinion poll since
> >>> debating this forever is not useful. So what are the options?
> >>> 
> >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> >>>  you use anyxml in a data model, the content will not appear in JSON
> >>>  encodings.
> >>> 
> >>> b) The JSON encoding defines that anyxml data is encoded as a string
> >>>  containing XML.
> >>> 
> >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> >>>  the implementor finds useful.
> >>> 
> >>> d) If the anyxml content is actually valid anydata content, encode it
> >>>  using anydata rules. Content that is not valid anydata content is
> >>>  not encoded at all.
> >>> 
> >>> Any options missing?
> >> 
> >> Yes, the one that's in yang-json-06:
> >> 
> >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> >>   value can be an object, array, number, string or one of the literals
> >>   "true", "false" and "null".
> >> 
> >> My preference is e), and then a).
> >> 
> > 
> > Is e) not the same as c)? I assume that the JSON encoding will always
> > be valid JSON (or I-JSON to be precise). So it seems the only refinement
> > of e) is the toplevel.
> 
> c) sounds like the same data can be encoded in different ways depending on 
> what the implementor finds useful, e.g. encode all numbers as strings.
>

But e) says the same, I fail to see the difference here.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Wed, Nov 11, 2015 at 7:32 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> >
> > > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > >>
> > >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >>>
> > >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > 
> > >
> > > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > >
> > > Since the use of anyxml limits the manipulation of the content, it
> is
> > > RECOMMENDED that the "anyxml" statement not be used to define
> > > configuration data.
> > >
> > > It should be noted that in YANG version 1, anyxml was the only
> > > statement that could model an unknown hierarchy of data.  In many
> > > cases this unknown hierarchy of data is actually modelled in YANG,
> > > but the exact YANG model is not known at design time.  In these
> > > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > > of anyxml.
> > 
> >  The first paragraph is for config data and the second for data that
> can modelled with YANG. If we want to deprecate "anyxml" for use with data
> that are neither of these, 6020bis should say so. I'd be fine with that.
> > 
> > >>>
> > >>> The guidelines will say that any usage of anyxml in the IETF will be
> > >>> carefully checked by YANG doctors. See Y34 for all details.
> > >>>
> > > There is more text in Y34-05 that will go into the guidelines. I
> call
> > > this "effectively deprecated", you can call it differently if you
> > > want. Frankly, this thread is about how to encode anyxml in JSON
> not
> > > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is
> what
> > > we ended up with.
> > 
> >  I am strongly against encoding serialized XML as JSON strings. It
> is IMO totally useless and the spec would have to deal with awkward
> complications because it is not true that arbitrary XML-encoded anyxml
> content can be used without changes in JSON encoding.
> > 
> >  Perhaps the best solution would be to state that JSON encoding is
> incompatible with data models that use "anyxml".
> > 
> > >>>
> > >>> Perhaps we can only settle this by doing an opinion poll since
> > >>> debating this forever is not useful. So what are the options?
> > >>>
> > >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> > >>>  you use anyxml in a data model, the content will not appear in JSON
> > >>>  encodings.
> > >>>
> > >>> b) The JSON encoding defines that anyxml data is encoded as a string
> > >>>  containing XML.
> > >>>
> > >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> > >>>  the implementor finds useful.
> > >>>
> > >>> d) If the anyxml content is actually valid anydata content, encode it
> > >>>  using anydata rules. Content that is not valid anydata content is
> > >>>  not encoded at all.
> > >>>
> > >>> Any options missing?
> > >>
> > >> Yes, the one that's in yang-json-06:
> > >>
> > >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> > >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> > >>   value can be an object, array, number, string or one of the literals
> > >>   "true", "false" and "null".
> > >>
> > >> My preference is e), and then a).
> > >>
> > >
> > > Is e) not the same as c)? I assume that the JSON encoding will always
> > > be valid JSON (or I-JSON to be precise). So it seems the only
> refinement
> > > of e) is the toplevel.
> >
> > c) sounds like the same data can be encoded in different ways depending
> on what the implementor finds useful, e.g. encode all numbers as strings.
> >
>
> But e) says the same, I fail to see the difference here.
>
>
IMO the only option is (f)

 f) If the anyxml content is actually valid anydata content, encode it
using anydata rules. Content that is not valid anydata content is
either not encoded at all, or encoded in an implementation-specific
manner


Nobody has answered my question about the "WEB banner" type of object.
The only reports we have ever heard on this sort of object indicate that
a leaf is used, NOT ANYXML!  Nobody seems to be using anyxml to store WEB
page snippets in their configuration.  Clearly a leaf is interoperable for
both XML and JSON, plus NETCONF or RESTCONF.  But we keep insisting
the YANG to JSON mapping needs to support this use of anyxml.

We use anyxml in RPC parameters in ietf-netconf, but the XML
is not expected to be mixed-mode XML.  Only elements and attributes
are used.


/js
>

Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> 

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> 
> > 
> > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > 
> >   Since the use of anyxml limits the manipulation of the content, it is
> >   RECOMMENDED that the "anyxml" statement not be used to define
> >   configuration data.
> > 
> >   It should be noted that in YANG version 1, anyxml was the only
> >   statement that could model an unknown hierarchy of data.  In many
> >   cases this unknown hierarchy of data is actually modelled in YANG,
> >   but the exact YANG model is not known at design time.  In these
> >   situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> >   of anyxml.
> 
> The first paragraph is for config data and the second for data that can 
> modelled with YANG. If we want to deprecate "anyxml" for use with data that 
> are neither of these, 6020bis should say so. I'd be fine with that.
>

The guidelines will say that any usage of anyxml in the IETF will be
carefully checked by YANG doctors. See Y34 for all details.

> > There is more text in Y34-05 that will go into the guidelines. I call
> > this "effectively deprecated", you can call it differently if you
> > want. Frankly, this thread is about how to encode anyxml in JSON not
> > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
> > we ended up with.
> 
> I am strongly against encoding serialized XML as JSON strings. It is IMO 
> totally useless and the spec would have to deal with awkward complications 
> because it is not true that arbitrary XML-encoded anyxml content can be used 
> without changes in JSON encoding. 
> 
> Perhaps the best solution would be to state that JSON encoding is 
> incompatible with data models that use "anyxml".
>

Perhaps we can only settle this by doing an opinion poll since
debating this forever is not useful. So what are the options?

a) The JSON encoding does not define anyxml is not encoded at all. If
   you use anyxml in a data model, the content will not appear in JSON
   encodings.

b) The JSON encoding defines that anyxml data is encoded as a string
   containing XML.

c) The JSON encoding defines that anyxml is encoded in whatever way
   the implementor finds useful.

d) If the anyxml content is actually valid anydata content, encode it
   using anydata rules. Content that is not valid anydata content is
   not encoded at all.

Any options missing?

Observations:

 - Except b), none of the options is interoperable. Option d) is
   interoperable for the anydata subset of anyxml.
 - It seems a) is simplest to implement, b) might be expensive to
   implement and use.
 - Some implementations use internal data stores that can only deal
   with data that can be modelled with YANG and for those implementations
   anyxml is effectively the same as anydata and d) migth be close to
   a) in terms of implementation costs.

Any other observations missing?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 11 Nov 2015, at 13:26, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Nov 11, 2015 at 11:54:58AM +0100, Ladislav Lhotka wrote:
>> 
>>> On 11 Nov 2015, at 09:07, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
 Andy Bierman  wrote:
> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> 
>> Hello,
>> 
>> I am not favor of it, either, but RFC6020 is here and is being widely
>> deployed. So is RESTCONF+JSON, which is favored by application developers
>> in the field today, as is NETCONF devices producing anyxml. We do need a
>> reasonable way of bridging the two -- no matter whether it is 
>> configuration
>> or operational data.
>> 
>> 
> 
> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> I do not agree that all the "extra XML bits" that are causing so much
> concern
> are ever saved in a datastore.  Martin says we need anyxml for RPC input
> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> operation depends on anything except elements and attributes.
 
 Specifically, we need anyxml for ietf-netconf, since NETCONF is
 supposedly data modeling language agnostic.
 
 One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
 if we ever do a new version of NETCONF, we use anydata instead.
 
>>> 
>>> We are effectively deprecating anyxml in YANG 1.1. We have reached
>>> agreement on Y34-05 and I do not see any new arguments popping up.
>> 
>> There is nothing in 6020bis indicating that "anyxml" is being deprecated.
>> 
> 
> I wrote 'effectively deprecated' and here is the text in 6020bis.
> 
>   Since the use of anyxml limits the manipulation of the content, it is
>   RECOMMENDED that the "anyxml" statement not be used to define
>   configuration data.
> 
>   It should be noted that in YANG version 1, anyxml was the only
>   statement that could model an unknown hierarchy of data.  In many
>   cases this unknown hierarchy of data is actually modelled in YANG,
>   but the exact YANG model is not known at design time.  In these
>   situations, it is RECOMMENDED to use anydata (Section 7.10) instead
>   of anyxml.

The first paragraph is for config data and the second for data that can 
modelled with YANG. If we want to deprecate "anyxml" for use with data that are 
neither of these, 6020bis should say so. I'd be fine with that.

> 
> There is more text in Y34-05 that will go into the guidelines. I call
> this "effectively deprecated", you can call it differently if you
> want. Frankly, this thread is about how to encode anyxml in JSON not
> about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
> we ended up with.

I am strongly against encoding serialized XML as JSON strings. It is IMO 
totally useless and the spec would have to deal with awkward complications 
because it is not true that arbitrary XML-encoded anyxml content can be used 
without changes in JSON encoding. 

Perhaps the best solution would be to state that JSON encoding is incompatible 
with data models that use "anyxml".

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
>> 
>>> 
>>> I wrote 'effectively deprecated' and here is the text in 6020bis.
>>> 
>>>  Since the use of anyxml limits the manipulation of the content, it is
>>>  RECOMMENDED that the "anyxml" statement not be used to define
>>>  configuration data.
>>> 
>>>  It should be noted that in YANG version 1, anyxml was the only
>>>  statement that could model an unknown hierarchy of data.  In many
>>>  cases this unknown hierarchy of data is actually modelled in YANG,
>>>  but the exact YANG model is not known at design time.  In these
>>>  situations, it is RECOMMENDED to use anydata (Section 7.10) instead
>>>  of anyxml.
>> 
>> The first paragraph is for config data and the second for data that can 
>> modelled with YANG. If we want to deprecate "anyxml" for use with data that 
>> are neither of these, 6020bis should say so. I'd be fine with that.
>> 
> 
> The guidelines will say that any usage of anyxml in the IETF will be
> carefully checked by YANG doctors. See Y34 for all details.
> 
>>> There is more text in Y34-05 that will go into the guidelines. I call
>>> this "effectively deprecated", you can call it differently if you
>>> want. Frankly, this thread is about how to encode anyxml in JSON not
>>> about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
>>> we ended up with.
>> 
>> I am strongly against encoding serialized XML as JSON strings. It is IMO 
>> totally useless and the spec would have to deal with awkward complications 
>> because it is not true that arbitrary XML-encoded anyxml content can be used 
>> without changes in JSON encoding. 
>> 
>> Perhaps the best solution would be to state that JSON encoding is 
>> incompatible with data models that use "anyxml".
>> 
> 
> Perhaps we can only settle this by doing an opinion poll since
> debating this forever is not useful. So what are the options?
> 
> a) The JSON encoding does not define anyxml is not encoded at all. If
>   you use anyxml in a data model, the content will not appear in JSON
>   encodings.
> 
> b) The JSON encoding defines that anyxml data is encoded as a string
>   containing XML.
> 
> c) The JSON encoding defines that anyxml is encoded in whatever way
>   the implementor finds useful.
> 
> d) If the anyxml content is actually valid anydata content, encode it
>   using anydata rules. Content that is not valid anydata content is
>   not encoded at all.
> 
> Any options missing?

Yes, the one that's in yang-json-06:

e) An anyxml instance is encoded as a JSON name/value pair which MUST
   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
   value can be an object, array, number, string or one of the literals
   "true", "false" and "null".


My preference is e), and then a).

Lada

> 
> Observations:
> 
> - Except b), none of the options is interoperable. Option d) is
>   interoperable for the anydata subset of anyxml.
> - It seems a) is simplest to implement, b) might be expensive to
>   implement and use.
> - Some implementations use internal data stores that can only deal
>   with data that can be modelled with YANG and for those implementations
>   anyxml is effectively the same as anydata and d) migth be close to
>   a) in terms of implementation costs.
> 
> Any other observations missing?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

Randy Presuhn <randy_pres...@mindspring.com> writes:

> Hi -
>
>>From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
>>Sent: Nov 11, 2015 5:44 AM
>>To: Ladislav Lhotka <lho...@nic.cz>
>>Cc: netmod@ietf.org
>>Subject: Re: [netmod] JSON encoding of anyxml
> ...
>>Observations:
>>
>> - Except b), none of the options is interoperable. Option d) is
>>   interoperable for the anydata subset of anyxml.
>> - It seems a) is simplest to implement, b) might be expensive to
>>   implement and use.
>> - Some implementations use internal data stores that can only deal
>>   with data that can be modelled with YANG and for those implementations
>>   anyxml is effectively the same as anydata and d) migth be close to
>>   a) in terms of implementation costs.
>>
>>Any other observations missing?
>
> The problem is similar to the ones that show up with ASN.1 "ANY"
> (but *not* "ANY DEFINED BY") in environments supporting multiple
> encoding rules / transfer syntaxes.
>
> For a recipient to *fully* decode something in such an environment,
> either the encoding has unambiguously identify the grammar of the
> bits in question, or the recipient has to have complete a priori
> knowledge of everything that could possibly be encountered in that
> context, along with any disambiguation logic.
>
> The "ANY DEFINED BY" construct meets that requirement, as long as
> each set of encoding rules properly supports the abstract syntax.
> ASN.1 "ANY" doesn't meet that requirement as soon as things like,
> for example, IMPLICIT tagging come into play.
>
> Netmod and netconf have painted themselves into a corner here:
>   (1) the grammar can't be deduced from an encoding
>   (2) the information identifying the grammar of the payload
>   is not present on the wire, nor is it available in
>   machine-readable form in the data model.  At best it'll
>   be handled on an ad hoc basis if a developer gets around
>   to it for a given leaf.

Right, that's exactly how I see it. Even if anyxml is deprecated in
standard modules, I believe it may be useful if an implementation has
the possibility to send some non-YANG data, for one reason or
another. The vendor can then write a one-off module for this purpose
and that's all.

Lada

>
> This means that, as a practical matter, it's not going to be
> practical or interoperable to treat the payloads of these types
> as anything other than (octet) strings for transport.  Attempts
> to convert a value based on the (wrapping) transfer syntax will
> only work for senders that know the payload's grammar.  Generic
> recipients and particularly relays would be Simply Out of Luck.
>
> Randy
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Randy Presuhn]

Hi -

>From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
>Sent: Nov 11, 2015 5:44 AM
>To: Ladislav Lhotka <lho...@nic.cz>
>Cc: netmod@ietf.org
>Subject: Re: [netmod] JSON encoding of anyxml
...
>Observations:
>
> - Except b), none of the options is interoperable. Option d) is
>   interoperable for the anydata subset of anyxml.
> - It seems a) is simplest to implement, b) might be expensive to
>   implement and use.
> - Some implementations use internal data stores that can only deal
>   with data that can be modelled with YANG and for those implementations
>   anyxml is effectively the same as anydata and d) migth be close to
>   a) in terms of implementation costs.
>
>Any other observations missing?

The problem is similar to the ones that show up with ASN.1 "ANY"
(but *not* "ANY DEFINED BY") in environments supporting multiple
encoding rules / transfer syntaxes.

For a recipient to *fully* decode something in such an environment,
either the encoding has unambiguously identify the grammar of the
bits in question, or the recipient has to have complete a priori
knowledge of everything that could possibly be encountered in that
context, along with any disambiguation logic.

The "ANY DEFINED BY" construct meets that requirement, as long as
each set of encoding rules properly supports the abstract syntax.
ASN.1 "ANY" doesn't meet that requirement as soon as things like,
for example, IMPLICIT tagging come into play.

Netmod and netconf have painted themselves into a corner here:
  (1) the grammar can't be deduced from an encoding
  (2) the information identifying the grammar of the payload
  is not present on the wire, nor is it available in
  machine-readable form in the data model.  At best it'll
  be handled on an ad hoc basis if a developer gets around
  to it for a given leaf.

This means that, as a practical matter, it's not going to be
practical or interoperable to treat the payloads of these types
as anything other than (octet) strings for transport.  Attempts
to convert a value based on the (wrapping) transfer syntax will
only work for senders that know the payload's grammar.  Generic
recipients and particularly relays would be Simply Out of Luck.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
> Andy Bierman  wrote:
> > On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> > 
> > > Hello,
> > >
> > > I am not favor of it, either, but RFC6020 is here and is being widely
> > > deployed. So is RESTCONF+JSON, which is favored by application developers
> > > in the field today, as is NETCONF devices producing anyxml. We do need a
> > > reasonable way of bridging the two -- no matter whether it is 
> > > configuration
> > > or operational data.
> > >
> > >
> > 
> > I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> > I do not agree that all the "extra XML bits" that are causing so much
> > concern
> > are ever saved in a datastore.  Martin says we need anyxml for RPC input
> > and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> > operation depends on anything except elements and attributes.
> 
> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> supposedly data modeling language agnostic.
> 
> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> if we ever do a new version of NETCONF, we use anydata instead.
>

We are effectively deprecating anyxml in YANG 1.1. We have reached
agreement on Y34-05 and I do not see any new arguments popping up.

The JSON encoding document has to specify the encoding of an
effectively deprecated construct that was designed to encode any XML.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:

> Hello,
>
> I am not favor of it, either, but RFC6020 is here and is being widely
> deployed. So is RESTCONF+JSON, which is favored by application developers
> in the field today, as is NETCONF devices producing anyxml. We do need a
> reasonable way of bridging the two -- no matter whether it is configuration
> or operational data.
>
>

I do not agree that the use of anyxml as arbitrary XML is deployed at all.
I do not agree that all the "extra XML bits" that are causing so much
concern
are ever saved in a datastore.  Martin says we need anyxml for RPC input
and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
operation depends on anything except elements and attributes.

If the JSON looks like a leaf, then no tool is going to analyse the string
to see if it a well-formed XML instance document, so it can be re-parsed.
Unless a JSON array or object is started, the tool will not
think it is dealing with any child nodes.

There are lots of things that NETCONF can do that are trimmed out of
RESTCONF.
JSON representation or raw XML seems really low priority to me.
Are there any use-cases? What processing instructions, character entities,
etc.
are being used in the wild already?  None? Don't we have enough real
problems to
solve without rat-holing over corner-cases all the time?


Andy




> At any rate, a simple string is not going to cut it, as it does not retain
> modeling context nor encoding details of the data being transported --
> rendering reliable automated translation impossible.
>
> Bye,
> Robert
>
> On 11/10/2015 03:19 AM, Andy Bierman wrote:
>
> Hi,
>
> I am not in favor of anything XML or JSON specific in YANG.
> In reality, nobody uses anyxml as a configuration data node,
> so an improper roundtrip translation from JSON to XML
> is not going to happen.
>
> Encoding anyxml as a string is not going to happen either.
> Not sure what the difference between 'anyxml' and 'type string'
> is at that point.
>
> Why does YANG even need a special type of leaf that is a blob of XML?
> Can't a single-quoted string serve that purpose?
>
>
> Andy
>
>
> On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga < n...@hq.sk>
> wrote:
>
>> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>>
>>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
 >anyxml as a string that has XML inside makes sense.

>>> The possibility of sending arbitrary (non-YANG) data in the native
>>> encoding can occassionally be useful, and even more so in JSON. For
>>> example, I have to work with a JSON-based format for specifying DNSSEC
>>> signing policies. While my plan is to eventually replace this format with
>>> YANG-modelled data, it would help me, as an interim solution, to simply
>>> send the data in the legacy format. That's why I want to retain the
>>> existing rules for JSON encoding of anyxml, unless something else is
>>> available. Sending XML documents as strings is still possible although IMO
>>> next to useless.
>>>
>>
>> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies
>> non-transparent in case the sender (a NETCONF NE) and receiver (an RESTCONF
>> application) have out-of-band knowledge of the data being sent over anyxml.
>> Given the proxy does not have this knowledge, it cannot reliably deal with
>> lists, as they lack a container element in XML encoding.
>>
>> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as
>> a separate well-known attribute?
>>
>> Bye,
>> Robert
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Martin Bjorklund]

Andy Bierman  wrote:
> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> 
> > Hello,
> >
> > I am not favor of it, either, but RFC6020 is here and is being widely
> > deployed. So is RESTCONF+JSON, which is favored by application developers
> > in the field today, as is NETCONF devices producing anyxml. We do need a
> > reasonable way of bridging the two -- no matter whether it is configuration
> > or operational data.
> >
> >
> 
> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> I do not agree that all the "extra XML bits" that are causing so much
> concern
> are ever saved in a datastore.  Martin says we need anyxml for RPC input
> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> operation depends on anything except elements and attributes.

Specifically, we need anyxml for ietf-netconf, since NETCONF is
supposedly data modeling language agnostic.

One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
if we ever do a new version of NETCONF, we use anydata instead.


/martin



> If the JSON looks like a leaf, then no tool is going to analyse the string
> to see if it a well-formed XML instance document, so it can be re-parsed.
> Unless a JSON array or object is started, the tool will not
> think it is dealing with any child nodes.
> 
> There are lots of things that NETCONF can do that are trimmed out of
> RESTCONF.
> JSON representation or raw XML seems really low priority to me.
> Are there any use-cases? What processing instructions, character entities,
> etc.
> are being used in the wild already?  None? Don't we have enough real
> problems to
> solve without rat-holing over corner-cases all the time?
> 
> 
> Andy
> 
> 
> 
> 
> > At any rate, a simple string is not going to cut it, as it does not retain
> > modeling context nor encoding details of the data being transported --
> > rendering reliable automated translation impossible.
> >
> > Bye,
> > Robert
> >
> > On 11/10/2015 03:19 AM, Andy Bierman wrote:
> >
> > Hi,
> >
> > I am not in favor of anything XML or JSON specific in YANG.
> > In reality, nobody uses anyxml as a configuration data node,
> > so an improper roundtrip translation from JSON to XML
> > is not going to happen.
> >
> > Encoding anyxml as a string is not going to happen either.
> > Not sure what the difference between 'anyxml' and 'type string'
> > is at that point.
> >
> > Why does YANG even need a special type of leaf that is a blob of XML?
> > Can't a single-quoted string serve that purpose?
> >
> >
> > Andy
> >
> >
> > On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga < n...@hq.sk>
> > wrote:
> >
> >> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
> >>
> >>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>  >anyxml as a string that has XML inside makes sense.
> 
> >>> The possibility of sending arbitrary (non-YANG) data in the native
> >>> encoding can occassionally be useful, and even more so in JSON. For
> >>> example, I have to work with a JSON-based format for specifying DNSSEC
> >>> signing policies. While my plan is to eventually replace this format with
> >>> YANG-modelled data, it would help me, as an interim solution, to simply
> >>> send the data in the legacy format. That's why I want to retain the
> >>> existing rules for JSON encoding of anyxml, unless something else is
> >>> available. Sending XML documents as strings is still possible although IMO
> >>> next to useless.
> >>>
> >>
> >> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies
> >> non-transparent in case the sender (a NETCONF NE) and receiver (an RESTCONF
> >> application) have out-of-band knowledge of the data being sent over anyxml.
> >> Given the proxy does not have this knowledge, it cannot reliably deal with
> >> lists, as they lack a container element in XML encoding.
> >>
> >> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as
> >> a separate well-known attribute?
> >>
> >> Bye,
> >> Robert
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >
> >
> >

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Robert Varga]

Hello,

I am not favor of it, either, but RFC6020 is here and is being widely 
deployed. So is RESTCONF+JSON, which is favored by application 
developers in the field today, as is NETCONF devices producing anyxml. 
We do need a reasonable way of bridging the two -- no matter whether it 
is configuration or operational data.


At any rate, a simple string is not going to cut it, as it does not 
retain modeling context nor encoding details of the data being 
transported -- rendering reliable automated translation impossible.


Bye,
Robert

On 11/10/2015 03:19 AM, Andy Bierman wrote:

Hi,

I am not in favor of anything XML or JSON specific in YANG.
In reality, nobody uses anyxml as a configuration data node,
so an improper roundtrip translation from JSON to XML
is not going to happen.

Encoding anyxml as a string is not going to happen either.
Not sure what the difference between 'anyxml' and 'type string'
is at that point.

Why does YANG even need a special type of leaf that is a blob of XML?
Can't a single-quoted string serve that purpose?


Andy


On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga > wrote:


On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:

Given the resolution of Y34 in YANG 1.1, Martin's proposal
to encode
>anyxml as a string that has XML inside makes sense.

The possibility of sending arbitrary (non-YANG) data in the
native encoding can occassionally be useful, and even more so
in JSON. For example, I have to work with a JSON-based format
for specifying DNSSEC signing policies. While my plan is to
eventually replace this format with YANG-modelled data, it
would help me, as an interim solution, to simply send the data
in the legacy format. That's why I want to retain the existing
rules for JSON encoding of anyxml, unless something else is
available. Sending XML documents as strings is still possible
although IMO next to useless.


I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF
proxies non-transparent in case the sender (a NETCONF NE) and
receiver (an RESTCONF application) have out-of-band knowledge of
the data being sent over anyxml. Given the proxy does not have
this knowledge, it cannot reliably deal with lists, as they lack a
container element in XML encoding.

Can we perhaps indicate the encoding of the anyxml data chunk in
JSON as a separate well-known attribute?

Bye,
Robert

___
netmod mailing list
netmod@ietf.org 
https://www.ietf.org/mailman/listinfo/netmod




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Andy Bierman]

Hi,

I am not in favor of anything XML or JSON specific in YANG.
In reality, nobody uses anyxml as a configuration data node,
so an improper roundtrip translation from JSON to XML
is not going to happen.

Encoding anyxml as a string is not going to happen either.
Not sure what the difference between 'anyxml' and 'type string'
is at that point.

Why does YANG even need a special type of leaf that is a blob of XML?
Can't a single-quoted string serve that purpose?


Andy


On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga  wrote:

> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>
>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>>> >anyxml as a string that has XML inside makes sense.
>>>
>> The possibility of sending arbitrary (non-YANG) data in the native
>> encoding can occassionally be useful, and even more so in JSON. For
>> example, I have to work with a JSON-based format for specifying DNSSEC
>> signing policies. While my plan is to eventually replace this format with
>> YANG-modelled data, it would help me, as an interim solution, to simply
>> send the data in the legacy format. That's why I want to retain the
>> existing rules for JSON encoding of anyxml, unless something else is
>> available. Sending XML documents as strings is still possible although IMO
>> next to useless.
>>
>
> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies
> non-transparent in case the sender (a NETCONF NE) and receiver (an RESTCONF
> application) have out-of-band knowledge of the data being sent over anyxml.
> Given the proxy does not have this knowledge, it cannot reliably deal with
> lists, as they lack a container element in XML encoding.
>
> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as a
> separate well-known attribute?
>
> Bye,
> Robert
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 05 Nov 2015, at 15:51, Juergen Schoenwaelder 
>  wrote:
> 
> Lada,
> 
> this seems to be related to YANG 1.1 issue Y34 which we concluded with
> consensus on Y34-05, which extends Y34-02. And Y34-02 says:
> 
>  'anyxml' would still be used to represent unrestricted XML, as is
>  done in NETCONF.
> 
> Your repeated attempts to generalize anyxml does not give us
> interoperability. In fact, Y34-05 says:
> 
>   - Document that implementations MAY have restrictions for anyxml and
> that anyxml is not necessarily interoperable; data model writers
> should use anydata whenever possible.
>   - The guidelines document should say that YANG Doctors will review
> each use of anyxml in IETF modules when YANG 1.1 is adopted to
> avoid its use whenever possible.
> 
> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
> anyxml as a string that has XML inside makes sense.

The possibility of sending arbitrary (non-YANG) data in the native encoding can 
occassionally be useful, and even more so in JSON. For example, I have to work 
with a JSON-based format for specifying DNSSEC signing policies. While my plan 
is to eventually replace this format with YANG-modelled data, it would help me, 
as an interim solution, to simply send the data in the legacy format. That's 
why I want to retain the existing rules for JSON encoding of anyxml, unless 
something else is available. Sending XML documents as strings is still possible 
although IMO next to useless.

Lada

> 
> /js
> 
> On Thu, Nov 05, 2015 at 02:54:56PM +0900, Ladislav Lhotka wrote:
>> Hi,
>> 
>> at the NETMOD session Martin proposed that JSON encoding of anyxml instances 
>> be changed so that it is required to contain a JSON string with well-formed 
>> XML serialization inside. His argument was that "xml" is part on the data 
>> node name and also that RFC 6020 says it is "an unknown chunk of XML". I 
>> think, however, that the name and definition were influenced by the fact 
>> that XML was the only encoding under consideration when 6020 was being 
>> written. IMO, the definition could thus be interpreted as "an unknown chunk 
>> of data that follows the syntax of the current encoding".
>> 
>> Note that similar ambiguity of interpretations applies to 6020 statements 
>> about NETCONF, edit-config etc. - we saw it in the discussion about 
>> auto-delete behaviour.
>> 
>> A practical problem of Martin's proposal is that it doesn't provide a 
>> symmetric option to send arbitrary JSON chunks in JSON encoding (that may or 
>> may not be modelled with YANG). An option would be to introduce a new data 
>> node "anyjson" but I think this is really a bad approach - shall we then 
>> also add "anycbor" etc.? IMO YANG statements and rules should be 
>> encoding-independent.
>> 
>> I still think the best option would be to introduce "anydata" with my 
>> definition above so that in XML encoding it would be equivalent to "anyxml", 
>> and deprecate "anyxml". We can also introduce a substatement that could 
>> state that the instances of a particular anydata node are required to be 
>> modellable in YANG.
>> 
>> BTW, it seems that yang-patch needs to be able to transfer anyxml instances, 
>> so is it really possible to exclude anyxml from anydata content?
>> 
>> Lada 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

Lada,

this seems to be related to YANG 1.1 issue Y34 which we concluded with
consensus on Y34-05, which extends Y34-02. And Y34-02 says:

  'anyxml' would still be used to represent unrestricted XML, as is
  done in NETCONF.

Your repeated attempts to generalize anyxml does not give us
interoperability. In fact, Y34-05 says:

   - Document that implementations MAY have restrictions for anyxml and
 that anyxml is not necessarily interoperable; data model writers
 should use anydata whenever possible.
   - The guidelines document should say that YANG Doctors will review
 each use of anyxml in IETF modules when YANG 1.1 is adopted to
 avoid its use whenever possible.

Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
anyxml as a string that has XML inside makes sense.

/js

On Thu, Nov 05, 2015 at 02:54:56PM +0900, Ladislav Lhotka wrote:
> Hi,
> 
> at the NETMOD session Martin proposed that JSON encoding of anyxml instances 
> be changed so that it is required to contain a JSON string with well-formed 
> XML serialization inside. His argument was that "xml" is part on the data 
> node name and also that RFC 6020 says it is "an unknown chunk of XML". I 
> think, however, that the name and definition were influenced by the fact that 
> XML was the only encoding under consideration when 6020 was being written. 
> IMO, the definition could thus be interpreted as "an unknown chunk of data 
> that follows the syntax of the current encoding".
> 
> Note that similar ambiguity of interpretations applies to 6020 statements 
> about NETCONF, edit-config etc. - we saw it in the discussion about 
> auto-delete behaviour.
> 
> A practical problem of Martin's proposal is that it doesn't provide a 
> symmetric option to send arbitrary JSON chunks in JSON encoding (that may or 
> may not be modelled with YANG). An option would be to introduce a new data 
> node "anyjson" but I think this is really a bad approach - shall we then also 
> add "anycbor" etc.? IMO YANG statements and rules should be 
> encoding-independent.
> 
> I still think the best option would be to introduce "anydata" with my 
> definition above so that in XML encoding it would be equivalent to "anyxml", 
> and deprecate "anyxml". We can also introduce a substatement that could state 
> that the instances of a particular anydata node are required to be modellable 
> in YANG.
> 
> BTW, it seems that yang-patch needs to be able to transfer anyxml instances, 
> so is it really possible to exclude anyxml from anydata content?
> 
> Lada 
>  
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod