Andy Bierman <a...@yumaworks.com> writes: > On Wed, Sep 16, 2015 at 1:11 PM, Ladislav Lhotka <lho...@nic.cz> wrote: > >> >> > 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. >> >> > > Hence the value of using real data nodes instead of 'anydata'. > The 'anydata' statement says "this is a subtree without any schema".
anyxml says the same. > So it doesn't really do much good to worry about encoding based on the > schema. > > But if a YANG module declares an 'anydata' node then the description-stmt > for that node (or maybe extensions) MAY contain normative instructions for > encoding the descendant nodes within an anydata subtree. > This impacts conformance for that module, not general conformance > for 'anydata'. > Yes, but the same thing can be done with anyxml, right? It has been demonstrated in RFC 6241, ietf-yang-patch and probably elsewhere, too, and it does the job. The use case of passing around literally "any XML" is really only theoretical, I think some kind of schema is always assumed. So I believe we don't need two data node types for this purpose. And an advantage of anyxml is that its definition (from YANG point of view) is clear and unambiguous, whereas for anydata the phrase "can be modelled with YANG" may be interpreted in different ways. We are introducing a dubious new concept in YANG 1.1 with no apparent gain. Lada > > Lada >> >> > > Andy > > > >> > >> > 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 >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
