Robert Varga <[email protected]> writes: > On 02/05/2019 15:12, Ladislav Lhotka wrote: >>> But this really means that YANG has two sorts of typedefs: >>> >>> (i) A regular typedef which is just an alias for a base type, perhaps with >>> some additional refinements that can all be handled automatically (e.g. >>> pattern statements, etc). In this scenario, I think that a compiler can >>> ignore the description, and process the typedef automatically. >>> (ii) An enhanced typedef that has additional semantics embedded into the >>> description statement that requires custom implementation of the typedef. >>> >>> Being able to distinguish these two cases in a programmatic way seems >>> useful to me, but perhaps it is just unnecessary noise. >> YANG assumes "powerful" descriptions in general. An option would be to find >> a way for specifying the canonical >> format in a machine-readable form. > > The way I understand typedefs (and use of restricted types in > leaf/leaf-list) as that the first such use defines a value domain and > any further references must strictly refer to a subset of that domain. > > Notably it does not seem to be sane to redefine the canonical format > once it has been set. > > I think the entire canonical format problem comes from the fact > ipv4-address is, unlike case (i), only a representation of a value > domain which is semantically 32 bits. > > That value domain has two functions that are different from plain old > string: > - equality > - total ordering > > Canonical representation deals with the first one, while also providing > interoperability with XPath. There is no current mechanism to address > the second one.
Yes. XML schema languages use the concept of lexical vs. value space, it is more general and more robust that the concept of canonical format. > > I find having a machine-readable marker (such as an extension) that a > value domain is being defined immediately useful -- it allows the > compiler to warn that a specific typedef needs additional work to get it > working as intended. This one's really easy. > > Having some (other) machine-readable marker of how a canonical value > looks like (i.e. similar to pattern) is also useful: it allows the > runtime to check if an incoming value is in canonical format and accept > it irrespective whether specific value domain support (from above) is > present or not. This one is moderately hard. > > Finally, some third marker, which would describe how to transform a > non-canonical string into a canonical string would obviously be awesome, > as now the runtime can work automatically. This one is really hard, > especially since the operations probably involve operating not on a > string, but some other representation. I liked the idea developed by Jeni Tennison for DSDL: https://slideplayer.com/slide/15172219/ (tl;dr: see slide 33). It seems though that this idea didn't materialize. Lada > > As in implementer, I really care about the first two -- they are easy to > do and provide immense value in making things work 'out of the box' and > automatically catching cases when they do not. > > Regards, > Robert > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
