Subject: [netmod] Y34: use cases for anydata

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 09:11:07 -0800

Hi,

Sometimes it helps to agree on the actual problems that
need to be solved, before we endlessly debate solutions.
I can only think of 4 use case classes for anydata.

Use case 1: root
-----------------------
Description: The anydata node MUST be a container (JSON object)
and the child nodes MUST be top-level YANG data nodes
supported by the server (i.e., TL-nodes defined in the YANG modules
advertised by the server)

Context: rpc/input and rpc/output

Examples: edit-config <config> node, get-config <data> node

Use case 2: fixed unknown schema node
-------------------------------------------------------
Description: The anydata node MUST be a container (JSON object)
and the child nodes MUST be instances of a specific YANG.
data-def-stmt, which does not have to be a TL-node.
The specific YANG object is not known to the server.

Context: data-model dependent; could be abstract data structure,
notification, operational data

Examples: A pass-through application such as a logger

Use case 3: fixed known schema node
-----------------------------------------------------
Description: The anydata node MUST be a container (JSON object)
and the child nodes MUST be instances of a specific YANG.
data-def-stmt, which does not have to be a TL-node.
The specific YANG object is known to the server
in some ad-hoc out-of-band manner.  No machine-readable
base YANG statements indicate the actual schema node.

Context: data-model dependent; could be abstract data structure,
notification, operational data

Examples: YANG Mount

Use case 4: dynamic schema node
-------------------------------------------------
Description: The anydata node MUST be a container (JSON object)
and the child nodes MUST be instances of any YANG.
data-def-stmt, which does not have to be a TL-node.
The specific YANG object may be known to the server
in some ad-hoc out-of-band manner.  No machine-readable
base YANG statements indicate the actual schema node.

Context: rpc/input, rpc/output, ???

Examples: YANG Patch

Summary
--------------
In each case, it should be OK to encode simple nodes as strings
and complex nodes as containers. The end consumer that is
expected to know the correct schema can convert from the
string to the correct YANG type.  There are corner cases
such as instance-identifier and QNames (e.g., identityref),
but I think these can also be handled correctly if specified
in the netmod-yang-json (and metadata) drafts in enough detail.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 09:22:59 -0800

Hi,

Actually, YANG Mount is use case (4) so maybe there are
only 3 types of anydata use-cases.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Jan 2015 19:44:55 +0100 (CET)

> I can only think of 4 use case classes for anydata.

*only* 4?  (or maybe 3).  I think these 3 use cases provide a pretty
 strong argument in favor of adding anydata.

Re. use case 3 or 4, I would argue that in both YANG patch and mount,
the server knows the schema.  So I'd scratch use case 4.

/martin

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 11:29:00 -0800

>  strong argument in favor of adding anydata.

The solution could be clarification of anyxml.
IMO that would be better that having a new keyword.

> the server knows the schema.  So I'd scratch use case 4.

The parser may not know the specific description-stmt requirements
of every YANG module implemented by the server.  Read my text.
The server knows the schema in some manner not machine-readable with
base YANG statements.

YANG Mount and Patch are both (4) because the specific node is
not fixed. It can be different for each instance, depending on the
which schema node is selected by the client for the target of
the anyxml.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 12:11:12 -0800

> the server knows the schema.  So I'd scratch use case 4.

use case (3) is the restconf-resource extension proposed for RESTCONF #15.

I do not strongly object to solution Y34-02 but it is confusing.
Is anyxml deprecated with this solution?
And anydata is just the clarified version of anyxml?

So text that could just be clarified for anyxml will be left untouched
and new text for anydata will be added that says basically the
same thing except that PIs and mixed content are not allowed in XML?
And anywhere anyxml is mentioned it will be changed to say anyxml and anydata?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Jan 2015 21:40:07 +0100 (CET)

> The server knows the schema in some manner not machine-readable with

The difference between 3 and 4, the way I read your description, is
that in 3 the server *knows* the schema, but in 4 the server may or
may not know the schema.  I think that in both YANG patch and mount,
the server knows the schema, thus they fall into category 3.

> which schema node is selected by the client for the target of

Right.  I thought this was 3.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Jan 2015 21:44:59 +0100 (CET)

> use case (3) is the restconf-resource extension proposed for RESTCONF #15.

But there is no anydata involved in this extension?

> Is anyxml deprecated with this solution?

I think it would still be needed in edit-config, since NETCONF is not
tied to YANG.

> same thing except that PIs and mixed content are not allowed in XML?

Either we say that anydata represents a structure that *could* be
modelled in YANG, or we say that it represents a structure that *is*
modelled in YANG.

> And anywhere anyxml is mentioned it will be changed to say anyxml and anydata?

I need to check the details, but basically yes, that's what needs to
be done.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 12:47:46 -0800

> Right.  I thought this was 3.

#3 is where the schema is always the same, like the content always
has to match the /restconf entry point schema.

#4 is configurable.  The exact schema will depend on other content
in the YANG Mount or Patch requests.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 12:58:23 -0800

> modelled in YANG, or we say that it represents a structure that *is*

No, we say anydata is YANG.

So tools are supposed to support anyxml and anydata now?
anyxml can be any XML the server accepts and anydata
has to be constrained (details TBD).

So is anyxml deprecated or not in this proposal?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Jan 2015 06:20:22 +0100

Hi,

I think there is also a use case where anydata conveys information that has some non-YANG schema. One example might be an Internet kiosk whose web pages can be edited through NETCONF. For this purpose it would actually be best to simply rename anyxml to anydata.

Lada
 
> On 23 Jan 2015, at 18:11, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 21:53:54 -0800

> I think there is also a use case where anydata conveys information that has some non-YANG schema. One example might be an Internet kiosk whose web pages can be edited through NETCONF. For this purp…

I do not agree with this use-case.
It does not exist in real implementations.
Mixed mode XML is complicated and standard translation
to JSON is not really worth the effort it would take.

IMO mixed mode should not be supported by anydata.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 24 Jan 2015 09:25:45 +0100

> I think there is also a use case where anydata conveys information that has some non-YANG schema. One example might be an Internet kiosk whose web pages can be edited through NETCONF. For this purp…

My understanding is this:

anyxml  = any XML (including mixed content, PIs, whatever, not
          necessarily interoperable)
	 
anydata = anything that conforms to the YANG restrictions on XML
          (no mixed content, no PIs, interoperable)

For me (as technical contributor), it seems sensible to have both and
it seem sensible to discourage usage of anyxml (at least withing IETF
data models).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Jan 2015 10:04:00 +0100

> On 24 Jan 2015, at 09:25, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Yes, but I’d also like to have a symmetric rule for JSON encoding, i. e. any valid JSON value. 

> it seem sensible to discourage usage of anyxml (at least withing IETF

I can agree with that, with the above caveat.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Jan 2015 10:19:36 +0100

> On 24 Jan 2015, at 06:53, Andy Bierman <[email-masked]> wrote:
> 

We won’t get very far if we limit ourselves to things that already exist in real implementations.

> to JSON is not really worth the effort it would take.

Any XML parser is able to parse mixed content. It is not our business to define translations of anyxml content from XML to JSON or vice versa.

> IMO mixed mode should not be supported by anydata.

It is already supported by anyxml. And it’s not only about mixed content. There is a lot of XML stuff around and some cannot be modelled with YANG. As another example, one might want to use anyxml for transporting OS X plist files. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 24 Jan 2015 09:25:50 -0800

>           necessarily interoperable)

Will "anyxml" be deprecated or not?
If YANG had a real conformance model like SMIv2, this would matter.

> it seem sensible to discourage usage of anyxml (at least withing IETF

+1

The modules have to get past YANG Doctors to get published in RFCs.
I am not likely to ever approve the use of anyxml, or the use of anydata
instead of a real data node definition.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 13:49:46 +0100

> Yes, but I’d also like to have a symmetric rule for JSON encoding, i. e. any valid JSON value. 

I am strongly against adding statements for every encoding that comes
along. We kind of learned that anyxml is problematic and hence it was
suggested to have an anydata type since it is restricted to anything
that can be defined in YANG. This is a sensible type from the
perspective of YANG. Having any<encoding-foo> is in my view not
helpful since it is by definition not interoperable (and for me it is
a layering violation as well).

During this discussion, we did also touch on the JSON I-D. Perhaps a few
things to clarify:

1) I am fine with encoding values into I-JSON taking YANG schema
   information into account. (I do not insist everything has to be
   encoded as a string.)

2) I am not fine with receivers failing because of a JSON type
   mismatch. I believe receivers MUST do any conversion necessary
   should the received JSON type not match the YANG type. (That is
   "42" must be interpreted as 42 if YANG says it is an int and
   "False" must be interpreted as False if YANG says the leaf is of
   type boolean.

3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON
   document saying the encoding of anyxml is implementation dependent
   (because we would say clearly in YANG 1.1 that anyxml is in the
   general case non-interoperable).

4) Assuming we adopt anydata in YANG 1.1, then I think the JSON
   document needs to specify how anydata is encoded in an
   interoperable way. And it needs to clarify how 2) applies, that is,
   at the point in time where anydata content is matched against a
   datamodel, conversions MUST be applied as necessary.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Jan 2015 15:58:45 +0100

> along. We kind of learned that anyxml is problematic and hence it was

I didn't say that. My proposal is to have the same rule for all
encodings, including XML: anyxml value is any content that's well-formed
for the given encoding.

>    information into account. (I do not insist everything has to be

OK.

>    "False" must be interpreted as False if YANG says the leaf is of

I disagree. The Postel principle you referred to asks senders to be
strict, but a sender that's aware of the YANG data model (and therefore
knows 42 is an integer) has no good reason for *not encoding* it as a
number.

You seem to be catering for senders that produce valid XML and then
apply YANG-unaware XML->JSON conversion. But this won't work anyway,
e.g. for single-entry lists and leaf-lists.

>    general case non-interoperable).

OK.

>    datamodel, conversions MUST be applied as necessary.

The JSON encoding spec *could* define a default schema-less XML<->JSON conversion
to be applied to an anydata node that doesn't define anything specific. 

I think 2) doesn't apply at all for an anydata node - it's outside the
scope for YANG.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jan 2015 07:08:23 -0800

> knows 42 is an integer) has no good reason for *not encoding* it as a

The YANG type is anyxml, which means there is no YANG type.
It makes no sense to say "the server knows this is an int".
The YANG schema says "anyxml". Period.

> e.g. for single-entry lists and leaf-lists.

I read this quite differently.
The Postel Principle says be liberal in what you accept.
It is quite trivial for the receiver to convert to a string which
can then be parsed by the end-user and converted to a YANG type.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 16:32:26 +0100

> encodings, including XML: anyxml value is any content that's well-formed

Maybe, it is non-interoperable, so it is something I do not care about
much.

> e.g. for single-entry lists and leaf-lists.

Yes, I do forsee situations where the _encoder_ does not know the YANG
type. There were a couple mentioned in the thread I think. Yes, the
receiver likely also has to be lenient with one element arrays that
map to a container or vice versa.

> I think 2) doesn't apply at all for an anydata node - it's outside the

Why is anydata outside the scope of YANG? I guess I disagree with this
statement.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Jan 2015 15:46:25 +0100

> The YANG schema says "anyxml". Period.

Juergen's item #2 above clearly talks about other nodes than anyxml.

> The Postel Principle says be liberal in what you accept.

No, it says this:

"Be conservative in what you send, be liberal in what you accept."

In fact, it's not meant as a guideline for protocol designers but rather
for protocol users: the sender should comply with the protocol, and the
receiver should reasonably tolerate protocol violations.

> can then be parsed by the end-user and converted to a YANG type.

It's equally trivial, e.g., to convert a received value of 42.0 to an
integer and I don't mind if a receiver follows the Postel principle and
performs this conversion - despite the fact that 42.0 is not a valid
value for a YANG integer.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Jan 2015 15:57:41 +0100

> map to a container or vice versa.

I don't agree, this would be S-JSON (sloppy JSON) rather than
I-JSON. Using the same logic, one could also require that receivers fix
the namespace of a received XML element if the namespace doesn't match
the namespace of the YANG node.

> Why is anydata outside the scope of YANG? I guess I disagree with this

Talking about your item #2 in the context of anyxml/anydata is outside
the scope of YANG because anyxml/anydata contents have no YANG types.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Jan 2015 07:09:03 -0800

> Juergen's item #2 above clearly talks about other nodes than anyxml.

Not sure what this means.
If the sender encodes "42" as a string and the final receiver that knows
YANG thinks it is an int32, then the receiver will convert the string "42"
to the YANG type int32, even though the JSON type was a string
instead of a number.

This seems clear and hard to interpret as a requirement on the sender.

> "Be conservative in what you send, be liberal in what you accept."

both parts, yes.

> receiver should reasonably tolerate protocol violations.

I disagree

> value for a YANG integer.

But "42.0" does not follow the rules for an int32 so this is a
strawman argument.
The sender will encode "42" and everything works fine.  Even if the
sender encodes a JSON number, everything works fine.  It is not difficult
to convert any JSON type to a YANG type (or reject it instead).

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jan 2015 16:12:04 +0100

> the namespace of the YANG node.

Sorry Lada, I can't follow your logic.

> the scope of YANG because anyxml/anydata contents have no YANG types.

My statement was that anydata is different from anyxml because we can
make it interoperable. #2 applies since anydata may _eventually_ be
matched against a data model, but not necessarily at the time the data
is encoded. Please go back in this thread to find examples related to
mounts etc.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Jan 2015 16:55:59 +0100

> On 27 Jan 2015, at 16:12, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I could have an XML encoder that doesn’t know YANG namespace URIs, so it just encodes all instances as XML elements with null namespace. Rules for XML encoding could state that the receiver MUST fix this -but they don’t. Is this really different from your requirements on JSON encoding?

It all comes down to the fact that all encodings are equal but the XML encoding is more equal. The benefit of JSON is that one can encode (typed) data structures directly into JSON, and vice versa. Anything else means extra work.

> is encoded. Please go back in this thread to find examples related to

As soon as the data are extracted and matched against a new YANG data model, it’s no more anydata and standard YANG rules apply. However, I assume two other cases are possible:

- some schema or protocol exists for the anydata content but it is not expressed in YANG,

- there is no schema.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Jan 2015 08:13:55 -0800

> I could have an XML encoder that doesn’t know YANG namespace URIs, so it just encodes all instances as XML elements with null namespace. Rules for XML encoding could state that the receiver MUST fi…

This is just an implementation detail.
The sender is required to encode the XML namespace correctly
for the anyxml node.  NETCONF/RESTCONF requires the sub-nodes of
this anyxml node to also be encoded correctly.

> It all comes down to the fact that all encodings are equal but the XML encoding is more equal. The benefit of JSON is that one can encode (typed) data structures directly into JSON, and vice versa.…

Only the YANG schema counts.  JSON is just an encoding format.
It is not being used to pass inline type information.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Jan 2015 17:18:45 +0100

> On 27 Jan 2015, at 16:09, Andy Bierman <[email-masked]> wrote:
> 

The receiving side could in principle fix many other type or structure violations, even in XML encoding. Another example: RFC 6020 requires list keys to go first, before other siblings in the same entry. However, it doesn’t require the receiver to silently fix the order if this rule is violated.

> This seems clear and hard to interpret as a requirement on the sender.

I want to require the server to use its data model knowledge and encode everything properly.

>> receiver should reasonably tolerate protocol violations.

Then read RFC 1122.

> But "42.0" does not follow the rules for an int32 so this is a

Likewise, the rule for encoding forty-two in JSON is to use a JSON number. A sender encoding it as a string doesn’t follow this rule.  

> The sender will encode "42" and everything works fine.  Even if the

Yes, the sender encodes it as a JSON number 42 and everything works fine.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jan 2015 18:09:09 +0100

> I could have an XML encoder that doesn’t know YANG namespace URIs, so it just encodes all instances as XML elements with null namespace. Rules for XML encoding could state that the receiver MUST fi…

Yes, I can convert a string into an int and vice versa but I can't
create a proper namespace out of nothing. I am surprised you do not
see these differences.
 
> It all comes down to the fact that all encodings are equal but the XML encoding is more equal. The benefit of JSON is that one can encode (typed) data structures directly into JSON, and vice versa.…

First, XML encoding is indeed more equal because it is used by NETCONF
and it will be mandatory to implement in RESTCONF as far as I can tell
from following the NETCONF discussion.

Second, I have nothing against encoding a YANG int32 into a JSON
number. But: I do not assume that the YANG type is _always_ known by
the encoder. Hence, I believe the YANG type must be considered
authoritative and in case the data model aware piece of code detects a
discrepancy, a conversion should be done rather than aborting with an
error. And yes, contrary to you, I do foresee situations where the
data model aware piece of code is not tightly integrated with the
encoder/decoder.

What drives me is interoperability. I personally happen to love all
possible data serialization formats equally little. ;-)

I do not think we make progress this way and we probably need to find
a way to do a mailing list hum to figure out where the _WG_ stands on
this issue and not just the two of us.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 08:44:08 +0100

> On 27 Jan 2015, at 18:09, Juergen Schoenwaelder <[email-masked]> wrote:
> 

That’s because I am retarded. But in fact a YANG-aware receiver can figure out the proper namespace as nicely as the type of a leaf.

> this issue and not just the two of us.

Agreed.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Jan 2015 09:10:57 +0100 (CET)

> this issue and not just the two of us.

At this point, I think it would be useful if you could take a step
back and formulate the problem.  I must I admit I got lost in the
discussion.  I *think* the issue now has to do with the json encoding
of anydata and anyxml, if we decide to introduce anydata?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 09:28:04 +0100

> On 28 Jan 2015, at 09:10, Martin Bjorklund <[email-masked]> wrote:
> 

Yes, the discussion sometimes wandered into areas that are unrelated to anyxml/anydata.

As for anydata, I’d be happy with just renaming anyxml to anydata, keeping the existing 6020 definition for XML encoding, and using the definition of JSON encoding that’s currently in draft-ietf-netmod-yang-json-02, sec. 5.5, and similarly for any future encoding: anydata means any content that’s well-formed for the given encoding (in the broader context of the entire datastore/document).

I understand that Andy wants to exclude XML mixed content, so I can also agree with adding restrictions for anydata in the sense that the content can *potentially* be modelled in YANG. The exact conditions are somewhat tricky because, for example, this XML snippet cannot be modelled in YANG:

<foo>42</foo>
<foo>
  <bar>hi</bar>
</foo>

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Jan 2015 10:06:46 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> As for anydata, I’d be happy with just renaming anyxml to anydata,

I don't think works.  It is not backwards compatible, and it would
break the definition in 6241.

My preference would be Y34-02 (keep anyxml, add anydata), with the
clarifications suggested by Juergen (discourage the usage of anyxml).

> I understand that Andy wants to exclude XML mixed content, so I can
> also agree with adding restrictions for anydata in the sense that the
> content can *potentially* be modelled in YANG.

Yes, I think we want to allow for the case where a consumer/producer
of 'anydata' does not know the YANG data model (generic logger, some
proxy, etc).  So "potentially" modelled in YANG should be fine.

The issue I see can be illustrated like this:

                       +--------+
  input w/ anydata --> | server | -- output -->
                       +--------+

I.e., some implementation gets data w/ anydata in it, and is supposed
to send this to some client that needs to be able to interpret this
data.

Let's assume the data is this:

  namespace urn:x;
   ...
  container x {
    anydata y;
  }

and one example of something we can put into this anydata is:

  namespace urn:foo;
  ...
  container foo {
    leaf bar {
      type int32;
    }
    leaf if-type {
      type identityref {
        base if:interface-type;
      }
    }
  }
    
  module ex-ethernet {
    namespace urn:exeth;
    ...
    identity ethernet { ... }
  }

So the input could be:

  (A)
  <x xmlns="urn:x">
    <y>
      <foo xmlns="urn:foo" xmlns:p0="urn:exeth">
        <bar>42</bar>
        <if-type>p0:ethernet</if-type>
      </foo>
    </y>
  </x>

There are four cases:

1.  input xml, output xml

  The problem here has to do with namespace prefixes.

  Suppose the input was received as:

  (B)
  <x xmlns="urn:x" xmlns:p1="urn:exeth">
    <y>
      <foo xmlns="urn:foo">
        <bar>42</bar>
        <if-type>p1:ethernet</if-type>
      </foo>
    </y>
  </x>

  The server doesn't know that if-type is of type identityref, so it
  doesn't know that "eth:" is a prefix.  It just stores everything as
  strings.  But when it returns this node to a client, it must make
  sure the prefix is declared properly.

  We can solve this for anydata by saying that 
  the anydata node must have all namespace declarations in the anydata
  subtree in the XML encoding.  Thus the input (B) would be illegal,
  but (A) legal.

2.  input json, output json

  In json, there are no namespace prefixes, so that is not an issue.
  Also, if both input and output is json, the implementation can store
  the data as received, and return it in the same way.

3.  input xml, output json

  This is tricky, since in order to produce correct json both for leaf
  'bar' and leaf 'if-type', the server needs schema knowledge; 'bar'
  must be encoded as 42 rather than "42", and 'if-type' must be
  encoded as "ex-ethernet:ethernet" rather than "p0:ethernet".

4.  input json, output xml

  Similar problems as in 3.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 10:51:31 +0100

> On 28 Jan 2015, at 10:06, Martin Bjorklund <[email-masked]> wrote:
> 

Well, yes, I mean keeping anyxml as a (deprecated) synonym. Which 6241 definition do you mean?

The advantage of this solution is that existing data formats (RDF comes to my mind) that have nothing in common with YANG can be potentially piggybacked in anydata. Andy will say such a use case doesn’t exist yet but I think this *might* be potentially useful. Assuming that YANG will become the universal schema language for network protocols is not realistic.

> The issue I see can be illustrated like this:

You probably mean “p1:” here. But if the server has the data model, it should know this is an identityref and “p1:” is a prefix, right?

>  encoded as "ex-ethernet:ethernet" rather than "p0:ethernet”.

It doesn’t make much sense to me that the server act as a transparent relay. I think one can assume that for every anydata node the server has a schema, although it needn’t be expressed in YANG.

If there really was a use case for a schema-agnostic server, we could define a default (and lossy) XML->JSON translation.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Jan 2015 11:10:52 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Well, yes, I mean keeping anyxml as a (deprecated) synonym.

Not synonym, since 'anyxml' truly is any xml, which 'anydata' is not.
And probably not deprecated, but rather "think twice before using".

> Which 6241
> definition do you mean?

rpc edit-config etc.  Search for anyxml.

> The advantage of this solution is that existing data formats (RDF
> comes to my mind) that have nothing in common with YANG can be
> potentially piggybacked in anydata. Andy will say such a use case
> doesn’t exist yet but I think this *might* be potentially
> useful. Assuming that YANG will become the universal schema language
> for network protocols is not realistic.
> 
> > 
> You probably mean “p1:” here.

Yes.

> But if the server has the data model, it
> should know this is an identityref and “p1:” is a prefix, right?

Sure.  The use case is about servers that do not know about the data
model.

> It doesn’t make much sense to me that the server act as a transparent
> relay. I think one can assume that for every anydata node the server
> has a schema, although it needn’t be expressed in YANG.

I would stay out of "needn't be expressed in YANG".  Let's just say
that the server knows the schema.

> If there really was a use case for a schema-agnostic server, we could
> define a default (and lossy) XML->JSON translation.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 11:25:51 +0100

> On 28 Jan 2015, at 11:10, Martin Bjorklund <[email-masked]> wrote:
> 
> And probably not deprecated, but rather "think twice before using”.

Do you mean that for modules containing anyxml no JSON encoding will be defined?

I’d prefer to keep the current definition in the yang-json draft even though anyxml is a misnomer. There are other formulations in 6020 that are XML- and NETCONF-specific.

> rpc edit-config etc.  Search for anyxml.

Sure, but it’s OK if anyxml continues to exist.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Jan 2015 02:29:07 -0800

> of anydata and anyxml, if we decide to introduce anydata?

I strongly agree with Juergen on the problem and the solution.

The problem is that the sender MAY choose a JSON encoding
format which is has some JSON type, even though the JSON
data type is meaningless within anyxml/anydata.

The solution is that the receiver MUST convert from the
provided JSON type to some YANG type.  If the sender
does not know the YANG schema, a safe encoding must
be picked (i.e., string).  A receiver that understands the
YANG schema MUST convert to the expected YANG type
if possible.  (e.g., Sending "purple" for a YANG boolean or
number will fail at the final receiver).

If the final YANG node is a boolean, then what difference
does it make if the input from the sender is 42 or "42"?
There is no benefit in "remembering" that a number was
sent vs. a string. The JSON type is totally irrelevant to
the transfer of anydata.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 12:05:21 +0100

> On 28 Jan 2015, at 11:29, Andy Bierman <[email-masked]> wrote:
> 

Why is string the only safe encoding? The data usually don’t appear out of nowhere - and inside an application they have some type. Why should be a sender forced to translating a number to a string instead of  passing it simply to a JSON encoder?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Jan 2015 12:22:03 +0100 (CET)

> Do you mean that for modules containing anyxml no JSON encoding will

The json doc has to say *something*, and maybe the current text is
fine.  It should be pointed out that the anyxml mapping is
implementation dependent.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 12:56:12 +0100

> On 28 Jan 2015, at 12:22, Martin Bjorklund <[email-masked]> wrote:
> 

The current text is:

   “This document defines no mapping between the contents of JSON- and XML-encoded anyxml instances.”

Isn’t it sufficient?

The -00 revision had a formulation that’s closer to what you suggest:

   “…, translation of anyxml contents is necessarily application-specific
   and outside the scope of this document.”

However, Juergen didn’t like it so I tried to reformulate it in a more neutral way.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Jan 2015 07:28:13 -0800

> Why is string the only safe encoding? The data usually don’t appear out of nowhere - and inside an application they have some type. Why should be a sender forced to translating a number to a string…

The sender MAY pick a JSON type if that makes the programmer happy.
It actually saves 2 bytes on the wire to send 42 instead of "42".

If the programmer designing the receiver thinks it is a good idea
to reject 42 because the "real" YANG is a string, not a number,
then that is their decision.  I would suggest designing code that
is not so brittle.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Jan 2015 17:20:46 +0100

> On 28 Jan 2015, at 16:28, Andy Bierman <[email-masked]> wrote:
> 
> It actually saves 2 bytes on the wire to send 42 instead of "42”.

It’s not about saving a few bytes on the wire but rather about keeping the interface between JSON encoding/decoding and an application simple and straightforward. If a leaf’s type is int32, then its value should also eventually end up in an integer variable, so all the processing can be just

integer variable -> JSON encoder -> transmission -> JSON parser -> integer variable

I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs or things like that are needed in the middle. 

Lada