Subject: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try)

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Feb 2015 21:41:53 +0100

Hi,

there has been quite some discussions around Y34 since the first
attempt to close the issue (the first VRFY :Y34: thread on this list).

I have read the following discussion and through the recent exchanges
in the thread "yang-json document" and while new solution proposals
have been made, I do not think they actually address the issue or add
anything to what has been discussed before. The discussion often seems
to be more centered around JSON encoding issues than Y34 itself,
perhaps this is also due to the original description of Y34. I think a
more accurate description of Y34 is this:

   The anyxml construct supports any XML, that is, it supports the
   whole XML infoset, including mixed content, processing
   instructions, document type declaration, etc. YANG defined data
   encoded in XML is much more restricted. This has led to a situation
   where some implementations only support a certain subset of XML for
   the anyxml construct. The anyxml construct also complicates
   alternate native encodings such as JSON.

Reviewing the discussion on the mailing list and during the virtual
interim meetings, I believe there is actually a rather clear path
forward, namely the adoption of Y34-05. To improve clarity, I have
rewritten Y34-05 (without changing its semantics, but trying to avoid
a chain of references to other solution proposals). Here is the new
text:

** Solution Y34-05

   Same as Y34-02 plus two guidelines adopted from Y34-04:

   - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This
     ensures backward compatibility.
   - Introduce a new 'anydata' statement that represents an unknown
     chunk of data that can be modeled with YANG.
   - 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.

The rationale is as follows:

  - The anyxml statement is defined very clearly in RFC 6020 to cover
    _any_ XML. Proposals to change the semantics of anyxml are not
    backwards compatible.
  - There is evidence that there are use cases where a mechanism similar
    to anyxml is needed that is restricted to the subset of data that
    can be defined in YANG.
  - There is evidence that some implementations of anyxml vary in their
    support of full XML.
  - It is desirable to _reduce_ encoding specific constructs in YANG,
    it is undesirable to add additional encoding specific constructs
    to YANG.

Please speak up by Friday 2015-02-20 if you have _strong_ objections
against this proposal. Please refrain from repeating arguments that
have been brought up before or discussing JSON encoding details (they
should be discussed in a different thread as they concern a seperate
document).

/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: Phil Shafer <[email-masked]>
Date: Mon, 16 Feb 2015 16:40:32 -0500

>     chunk of data that can be modeled with YANG.

I'd be opposed to introducing anydata.  It's a bit too much like
introducing a hole into the model.  Sure, the server assumably knows
what's there, but it's still a new feature.  The current charter
says:

   - YANG 1.1 is not adding fundamentally new data modeling concepts to the language.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Feb 2015 16:08:59 -0800

>    - YANG 1.1 is not adding fundamentally new data modeling concepts to the language.

The problem with anydata is that it is a generic attempt to fix all uses
of anyxml.

Each of the anyxml use-cases in RFCs and I-Ds is really a
poor man's substitutionGroup macro (from XSD), or a node
acting as the root for top-level YANG data nodes.

Using anydata as a free-form hole in the datastore is a bad idea.
Introducing anydata seems to require a server to support this,
as well as support mixed mode XML (since anyxml is still current,
and that seems to be the only difference from anydata).

IMO Y34 is in scope because anyxml is not being used as a leaf
holding a blob of HTML, as envisioned by the WG when RFC 6020
was written.  The solution might make the problem worse, not better.
IMO a solution that addresses the 2 actual use-cases for anyxml
is needed.

>  Phil

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Feb 2015 13:42:49 +0100

>    - YANG 1.1 is not adding fundamentally new data modeling concepts to the language.

I do not buy this argument. Y34 is addressing issues that have
surfaced with the usage of anyxml. Since we can't simple change the
semantics of anyxml (for backwards compatibility reasons), the obvious
solution is to create a replacement for the situations where "any data
that can be defined in YANG is needed" and to discourage the usage of
anyxml.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Feb 2015 13:48:42 +0100

> IMO a solution that addresses the 2 actual use-cases for anyxml

I am not sure I understand the '2 actual use-cases' (or why there are
only two). Anyway, you need to writeup a proper solution proposal if
you think the one we so far agreed on (Y34-05) is fundamentally flawed.
And it might help if you can explain more precisely why anydata will
be worse than having anyxml.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 24 Feb 2015 09:37:42 -0500

>that can be defined in YANG is needed" and to discourage the usage of

I don't understand the need to discourage the use of anyxml.  I
don't get why it suddenly became scary or dangerous.  It's a chunk
of XML data, which is a useful datatype regardless of the encoding
scheme used to transport it.

anyxml is simple and easy to understand.  You may not like it or
want to use it, but it's concrete and well defined.

In contrast, anydata implies something more intangible, where we
are saying that there's a chunk of data here that has a data model,
but you may not know what that model is.  This implies that you may
or may not know how to marshal or unmarshal it, how to insert/delete/rename
data within it, etc.  It's no longer a simple datatype.  It's alive,
complex, and governed by unknown rules.  Yes, the server understands
the data model (assumably), but it still seems wrong.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 Feb 2015 08:32:58 -0800

> be worse than having anyxml.

I don't think the backward compatibility argument holds because nobody actually
implemented it.  In order for there to be interoperability, there needs to be
implementations.

I get the fact that anyxml is perfect for a leaf called "web-banner".
Too bad nobody actually does that with anyxml.

So I am confused about all the great standards success we are preserving
with anyxml. The only advocates don't actually have implementations.

If anyxml is so great, then declare this issue dead.
No need to change anything.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Feb 2015 10:26:47 +0100

> scheme used to transport it.

I agree that occasionally it might be needed to send schemaless on
non-YANG data. If it's not HTML, it could be RDF or some other "legacy"
stuff. It is true for XML and I think even more so for JSON these days.

So my only problem with anyxml is the "xm"' in its name. I think nothing
prevents a data modeller from restricting a *particular* anyxml node so
that, e.g., the data has to correspond to a YANG model - known or unknown.

Lada

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