Subject: [netmod] YANG1.1 issue: remove anyxml statement

From: chong feng <[email-masked]>
Date: Fri, 4 Apr 2014 17:48:08 +0800

anyxml statement is assumed the data based yang model will be represent
with XML. But in restconf, it can be represent with json. So anyxml can not
express this situation.

I suggest remove anyxml statement,instead of anydata statement. And add
format substatement to
express format,such as xml,json,etc. xml is default.

for example:

anydata data {
    format json.
}

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Apr 2014 03:07:14 -0700

Hi,

I do not understand this issue.
The anyxml statement works in RESTCONF and works in JSON.

Andy

On Fri, Apr 4, 2014 at 2:48 AM, chong feng <[email-masked]> wrote:

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 4 Apr 2014 13:35:39 +0200

> The anyxml statement works in RESTCONF and works in JSON.

The proposal, as I understand it, tries to replace “anyxml” with a more neutral name. I agree it is a bit weird that “any XML” can also mean “any JSON".

Lada

> anyxml statement is assumed the data based yang model will be represent with XML. But in restconf, it can be represent with json. So anyxml can not express this situation.
> 
> I suggest remove anyxml statement,instead of anydata statement. And add format substatement to 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 04 Apr 2014 13:50:17 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> The proposal, as I understand it, tries to replace “anyxml” with a more neutral
> name.

The proposal also adds a format parameter.  I think that should be
avoided; since it means you have to know the format when you write the
data model (now we're getting into the problems of trying to have a
protocol neutral modelling language...)

> I agree it is a bit weird that “any XML” can also mean “any JSON".

+1

We could keep 'anyxml' for backwards compatibility, and add 'anydata'
(with no 'format').

But I wonder if it works... anyxml puts no restrictions on the xml, so
it cannot in general be translated to JSON.  Maybe we could keep
anyxml as is, and also add anydata.  Unclear if this solves anything
though.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Apr 2014 05:01:45 -0700

On Fri, Apr 4, 2014 at 4:50 AM, Martin Bjorklund <[email-masked]> wrote:

> > The proposal, as I understand it, tries to replace "anyxml" with a more
> neutral
> > name.
>
I don't understand the format-stmt at all.
Only protocol messages have an encoding, and they are just representations.
XML vs. JSON is not a property of the data model.

> I agree it is a bit weird that "any XML" can also mean "any JSON".
>
> +1
>
This is not worth changing (although I argued for the name 'any'
because that is what NCX implemented ;-)

We would have to keep 'anyxml' and then keep explaining that
there is no difference at all between 'anyxml' and 'anydata'.

Any time there are multiple ways to do the same thing, it causes
operators and developers to spend time figuring out exactly how they
are different, and when to use each one.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 04 Apr 2014 14:08:13 +0200 (CEST)

> because that is what NCX implemented ;-)

I think you are right.

> there is no difference at all between 'anyxml' and 'anydata'.

anyxml is unrestricted xml (including mixed content etc), and always
  xml (should be xml also in the json mapping, imo).
  anyxml should be used only when the format is known to be xml, like
  current NETCONF edit-config.

anydata would be an unknown chunk of data that can be modelled with
  YANG.  can be encoded as xml or json.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Apr 2014 05:13:29 -0700

>   current NETCONF edit-config.
But we do not allow mixed mode XML in NETCONF messages so how would
the <edit-config> ever contain that?

What if I write a YANG module that I want to use with RESTCONF and/or
NETCONF
(that is, all of them :-)

>   YANG.  can be encoded as xml or json.
Since we are adding your attribute encoding to Lada's JSON draft,
there is no trouble encoding attributes and elements.  That should be
good enough.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 4 Apr 2014 14:43:20 +0200

On 04 Apr 2014, at 13:50, Martin Bjorklund <[email-masked]> wrote:

> protocol neutral modelling language…)

I suspect the proposal confuses the schema with instance, perhaps the format parameter was intended to be used in an instance with a similar role as media-type. Maybe it could be done using an attribute.

> (with no 'format’).

+1

> it cannot in general be translated to JSON.  Maybe we could keep

I think the question of whether some representation can be translated to another is not important. With

anydata foo;

this should be OK:

<foo media-type=“application/json”>
“bar”: {
  …
}
</foo>
 
Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Apr 2014 15:08:15 +0200

> express format,such as xml,json,etc. xml is default.

As technical contributor, I am fine with the subject line but not with
the proposal. I think we should declare anyxml as deprecated and move
on. Allowing arbitrary blobs of data and even making it an art by
supporting different formats of arbitrary blobs of data does not lead
to interoperability.

/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: Martin Bjorklund <[email-masked]>
Date: Fri, 04 Apr 2014 15:22:31 +0200 (CEST)

This is now Y34.

Three proposed solutions are added.

/martin

---

From: chong feng <[email-masked]>
Date: Sat, 5 Apr 2014 23:30:25 +0800

---------- Forwarded message ----------
From: chong feng <[email-masked]>
Date: 2014-04-05 22:23 GMT+08:00
Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement
To: Martin Bjorklund <[email-masked]>

I agree 'remove format sub statement from anydata'. Anydata statement will
be only used to define the data based on YANG schema.
The encoding is decided by operation protocol ,such as NETCONF.

BTW, I wonder whether adding a new substatment named 'path' to express the
data must be based on determined path.
For example:
rpc get-interfaces-statistics {

      input {
             container interfaces {
                    list interface {
                          key ifname;
                          leaf ifname {
                                type string;
                          }
                    }
             }
      }
      output {
            anydata data {
            path if:interfaces-state/if:interface/if:statistics;
            }
      }

}

2014-04-04 21:22 GMT+08:00 Martin Bjorklund <[email-masked]>:

This is now Y34.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Apr 2014 17:37:54 +0200

Why not simply use a <get> with a filter?

/js

---

From: chong feng <[email-masked]>
Date: Sat, 5 Apr 2014 23:50:58 +0800

<get> is too common, a special rpc will be easy to handle, just like one
command line.

---

From: Andy Bierman <[email-masked]>
Date: Sat, 5 Apr 2014 09:39:07 -0700

> <get> is too common, a special rpc will be easy to handle, just like one

I don't think this approach scales at all.
Custom operations for retrieval should be information that
cannot be easily obtained with <get> or <get-config>.

See the <active-route> or <route-count> RPCs in the ietf-routing module
for examples of appropriate custom retrieval operations.

The 'path' statement looks like something that should be
a vendor extension to assist a server implementation.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 05 Apr 2014 18:46:18 +0200 (CEST)

+1

+1

/martin