Martin Bjorklund <[email protected]> writes: > Andy Bierman <[email protected]> wrote: >> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga <[email protected]> wrote: >> >> > Hello, >> > >> > I am not favor of it, either, but RFC6020 is here and is being widely >> > deployed. So is RESTCONF+JSON, which is favored by application developers >> > in the field today, as is NETCONF devices producing anyxml. We do need a >> > reasonable way of bridging the two -- no matter whether it is configuration >> > or operational data. >> > >> > >> >> I do not agree that the use of anyxml as arbitrary XML is deployed at all. >> I do not agree that all the "extra XML bits" that are causing so much >> concern >> are ever saved in a datastore. Martin says we need anyxml for RPC input >> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF >> operation depends on anything except elements and attributes. > > Specifically, we need anyxml for ietf-netconf, since NETCONF is > supposedly data modeling language agnostic. > > One option could be to deprecte anyxml (or remove it) in YANG 1.1, and > if we ever do a new version of NETCONF, we use anydata instead.
The simplest solution in this case would be to use a standard XML schema language - XSD or RELAX NG. Lada > > > /martin > > > >> If the JSON looks like a leaf, then no tool is going to analyse the string >> to see if it a well-formed XML instance document, so it can be re-parsed. >> Unless a JSON array or object is started, the tool will not >> think it is dealing with any child nodes. >> >> There are lots of things that NETCONF can do that are trimmed out of >> RESTCONF. >> JSON representation or raw XML seems really low priority to me. >> Are there any use-cases? What processing instructions, character entities, >> etc. >> are being used in the wild already? None? Don't we have enough real >> problems to >> solve without rat-holing over corner-cases all the time? >> >> >> Andy >> >> >> >> >> > At any rate, a simple string is not going to cut it, as it does not retain >> > modeling context nor encoding details of the data being transported -- >> > rendering reliable automated translation impossible. >> > >> > Bye, >> > Robert >> > >> > On 11/10/2015 03:19 AM, Andy Bierman wrote: >> > >> > Hi, >> > >> > I am not in favor of anything XML or JSON specific in YANG. >> > In reality, nobody uses anyxml as a configuration data node, >> > so an improper roundtrip translation from JSON to XML >> > is not going to happen. >> > >> > Encoding anyxml as a string is not going to happen either. >> > Not sure what the difference between 'anyxml' and 'type string' >> > is at that point. >> > >> > Why does YANG even need a special type of leaf that is a blob of XML? >> > Can't a single-quoted string serve that purpose? >> > >> > >> > Andy >> > >> > >> > On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga < <[email protected]>[email protected]> >> > wrote: >> > >> >> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote: >> >> >> >>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode >> >>>> >anyxml as a string that has XML inside makes sense. >> >>>> >> >>> The possibility of sending arbitrary (non-YANG) data in the native >> >>> encoding can occassionally be useful, and even more so in JSON. For >> >>> example, I have to work with a JSON-based format for specifying DNSSEC >> >>> signing policies. While my plan is to eventually replace this format with >> >>> YANG-modelled data, it would help me, as an interim solution, to simply >> >>> send the data in the legacy format. That's why I want to retain the >> >>> existing rules for JSON encoding of anyxml, unless something else is >> >>> available. Sending XML documents as strings is still possible although >> >>> IMO >> >>> next to useless. >> >>> >> >> >> >> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies >> >> non-transparent in case the sender (a NETCONF NE) and receiver (an >> >> RESTCONF >> >> application) have out-of-band knowledge of the data being sent over >> >> anyxml. >> >> Given the proxy does not have this knowledge, it cannot reliably deal with >> >> lists, as they lack a container element in XML encoding. >> >> >> >> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as >> >> a separate well-known attribute? >> >> >> >> Bye, >> >> Robert >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > >> > >> > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
