> On 16 Sep 2015, at 21:29, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > On 16 Sep 2015, at 20:25, Andy Bierman <a...@yumaworks.com> wrote: > > > > > > > > On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > > > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder > > > <j.schoenwael...@jacobs-university.de> wrote: > > > > > > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote: > > >> > > >> It can be stated in the description of the anydata statement. One can > > >> then ask though why we need two constructs - anyxml and anydata - > > >> because a data model can be specified in the description of an anyxml > > >> statement as well. > > >> > > > > > > The data model used by anydata content is clearly identified. The > > > > Hmm, how is it clearly identified? There needn’t be any data model at all. > > > > > difference between anyxml and anydata has been discussed at length and > > > we should not go there again. > > > > Then the 6020bis doesn’t make this difference clear, to me at least. > > > > > > This is an academic exercise, but the difference is very clear. > > > > The "anyxml" node allows XML-specific details like processing instructions. > > It is a blob of XML. It is not JSON. It is not YANG. It is XML. > > This is academic, because the vast majority of servers do not support anyxml > > at all. None. Zero. Not allowed in the server. The few that do treat > > anyxml > > as if it were anydata. > > > > The "anydata" node is a blob of YANG data nodes. It is not XML. > > It is not JSON. This too will likely not be implemented in the vast majority > > of servers. > > This is illusory unless a YANG data model is available, and, as you said, > this is not guaranteed. For one, without a data model there is no way for > mapping XML encoding to JSON and vice versa, so anydata received in one > encoding cannot be sent back to clients supporting the other encoding. > > > > I don't like the idea of adding a requirement that the "hidden schema" be used > so that JSON people will be happy to get a number instead of a string, as if > that is actually a data model.
Without a data model we also cannot map module names to XML namespaces. Lada > > Unless there is a hidden schema, then it just doesn't matter if the client > passed in a JSON number and another client reads back an XML string. > There is no data model at all. There is not even any schema that > says 'foo' can have any child nodes or not, let alone the required > QName and syntax for that child node. > > Users that want any sort of schema-based interoperability should not > use anydata instead of real data nodes. > > > > Lada > > Andy > > > > > > > > > > Lada > > > > > > > > > > > > /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/> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > 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
