On Tue, Sep 29, 2015 at 10:28:28AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > > > On Wed, Sep 23, 2015 at 03:46:27PM +0200, Ladislav Lhotka wrote: > >> > >> > On 23 Sep 2015, at 15:11, Juergen Schoenwaelder > >> > <j.schoenwael...@jacobs-university.de> wrote: > >> > > >> > On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote: > >> >>>> > >> >>>> I must admit I am getting lost in these discussions. It seems to me > >> >>>> there is a lot of hand-waving and hidden assumptions that moreover > >> >>>> differ from one person to another. As I already said in Prague, both > >> >>>> anyxml and anydata are IMO constructs of marginal utility and it is > >> >>>> frustrating we spend so much effort on them. > >> >>>> > >> >>> > >> >>> I agree that anyxml is of marginal utility, anydata however is needed > >> >>> for any rpc/action/notification or future language construct that can > >> >>> work with generic YANG content and hence I think its behaviour and > >> >>> encoding should be well defined. > >> >> > >> >> But then I believe we should have stricter rules for anydata than just > >> >> "an unknown set of nodes that can be modelled with YANG" - it should be > >> >> stated that the data model for an anydata instance MUST be known at > >> >> run-time. Otherwise I think anyxml can cover all use cases you mention > >> >> as well (as it has done in the past), and there is no need to introduce > >> >> a new data node type with a definition that allows for multiple > >> >> interpretations. > >> >> > >> > > >> > Lada, we are not repeating the discussion. It was long and painful > >> > enough and we finally accepted and verified Y34-05. If you have better > >> > wording to propose, feel free to make a proposal. But I am not going > >> > to open Y34 again just because you still do not like it. > >> > >> Experience has shown that the current formulation is understood > >> differently by different people. > >> > >> Earlier in this thread, you proposed this text to be added to the > >> yang-json spec: > >> > >> An anydata data node can contain an unknown set of nodes that can > >> be modelled by YANG. A data model for anydata content may or may > >> not exist at run time. If the data model for anydata content is > >> available, then the anydata content MUST be encoded according to > >> the rules of this specification. If the data model for anydata > >> content is not available, the encoding MUST follow the rules of > >> this specification except for rules that require data model > >> knowledge (and as a consequence, numbers may appear as strings or > >> namespace qualifiers may not match module names). > >> > >> So let me repeat: shouldn’t this text really go to 6020bis? Or do you > >> think that XML encoding needn’t abide by the data model if it is known? > >> > > > > Are you suggesting there should be similar text for the XML encoding or > > are you suggesting there should be abstract text for all encodings? > > I think it should be an encoding-independent statement - if the data > model is known, then anydata contents should be essentially no different > from a regular data (sub)tree.
Can you make a concrete proposal how to change the text in section 7.10 of draft-ietf-netmod-rfc6020bis-07.txt? And then please post it as a separate thread so we can track it as YANG 1.1 last call comment. > > RFC6020bis says currently: > > > > An anydata node is encoded as an XML element. The element's local > > name is the anydata's identifier, and its namespace is the module's > > XML namespace (see Section 7.1.3). The value of the anydata node is > > a set of nodes, which are encoded as XML subelements to the anydata > > element. > > Note, however, that this still includes contents that cannot be modelled > in YANG. The rules in the yang-json document (sec. 5.5) are similar but > they also try to exclude data that can never come from YANG. > > > > > Perhaps it means 'set of data nodes' where it says 'set of nodes'. The > > main difference here is that encoding anydata into XML is somewhat > > easier since you do not need to know whether 42 has to be encoded as a > > string or a number etc. > > > >> > That said, "MUST be known at run-time" may already fall apart with the > >> > mount proposals discussed in NETCONF (or it is sufficiently unclear to > >> > whom it MUST be known). > >> > >> To the server and client so that they both work with the same data > >> model. Of course, it is true that currently there are no means for > >> passing this information (either way) but I guess your text above > >> suffers from the same problem: how can you tell whether the data > >> model for anydata content is available or not? > >> > > > > The example is a RESTCONF server mounting data from a remove datastore > > and using JSON encoding when talking to RESTCONF clients. Do we > > require that such a server has to have knowledge about the data model > > mounted in order to get the encoding right? Or do we expect that the > > RESTCONF client can deal with situations where encodings may not 100% > > match the data model (e.g. lack of type knowledge, lack of namespace > > to module name mappings). > > This is not clear to me. I think access to remote content and schema > availability are orthogonal problems. I wanted to provide an example demonstrating that schema availability is not always guaranteed and since (i) JSON and XML use different ways to encode namespaces and (ii) JSON assumes some type information to be available while XML does not encode any type information, the example outlined above will either be expensive to implement (the mount server essentially has to grab all necessary data models while mounting something from a remote datastore) or it will produce encodings that require the client to very lenient in order to interoperate. Yes, in an ideal world, these would be orthogonal problems but due the differences how the encodings work, they are not as orthogonal as one might think. /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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
