Re: [netmod] type equivalence

[Martin Björklund <[e-mail]>]

"Rob Wilton \(rwilton\)" <rwilton=[e-mail]> wrote:
> 
> 
> > -----Original Message-----
> > From: netmod <[e-mail]> On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: [e-mail]
> > Subject: Re: [netmod] type equivalence
> > 
> > Here is an attempt to come up with better wording. If people agree on
> > a new wording, I volunteer to submit an errata.
> > 
> > OLD
> > 
> >    o  A "type" statement may be replaced with another "type" statement
> >       that does not change the syntax or semantics of the type.  For
> >       example, an inline type definition may be replaced with a typedef,
> >       but an int8 type cannot be replaced by an int16, since the syntax
> >       would change.
> > 
> > NEW
> > 
> >    o  A "type" statement may be replaced with another "type" statement
> >       that does not change the semantics of the type or the underlying
> >       built-in type.  For example, an inline type definition may be
> >       replaced with a semantically equivalent typedef derived from the
> >       same built-in type, but an int8 type cannot be replaced by an
> >       int16, since the underlying built-in type would change.
> [RW] 
> 
> Would the text be more clear it is just specified what is allowed, e.g.,
> 
>      o  A "type" statement may be replaced with another "type" statement
>         that resolves to the same underlying built-in type.  For example,
>         ...
> 
> 
> What does "semantics of the type" cover?

Suppose you have:

   typedef "timestamp" {
     type yang:date-time;
     description
       "The time that an event occurred";
   }

then you can't change it to:

   typedef "timestamp" {
     type yang:date-time;
     description
       "The time that an event was received.";
   }

The syntax is the same, but the semantics are different.


/martin




> 
> If I have this type:
> 
>   typedef "timestamp" {
>     type "string";
>     description
>       "The time of day that an event occurred, in any format";
>   }
> 
> then can I replace it with this definition:
> 
>   typedef "timestamp" {
>     type "string";
>     description
>       "The time of day, and optionally date, that an event
>        occurred, in any format";
>   }
> 
> 
> 
> Tangentially, it is worth noting the RFC 8342 also writes about syntactic
> constraints covering types:
> 
> 5.3.  The Operational State Datastore (<operational>)
> 
>    Syntactic constraints MUST NOT be violated, including hierarchical
>    organization, identifiers, and type-based constraints.  If a node in
>    <operational> does not meet the syntactic constraints, then it
>    MUST NOT be returned, and some other mechanism should be used to flag
>    the error.
> 
> I'm not sure how clear RFC 8342 section 5.3 is about returning values
> that can be represented by the underlying built-in-type, but are outside
> the value space defined by a range, length, or pattern statement.
> 
> My memory during the discussions was that it is allowed to return a value
> outside arange, length, pattern statement, as long as it is contained
> in the value space of the built-in-type.  E.g., cannot return 257 in a
> uint8, but can return 11 even if the type range is 1..10.
> 
> But, I'm not sure that is what the text actually states.
> 
> Regards,
> Rob
> 
> 
> > 
> > /js
> > 
> > On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote:
> > > On 2021-02-22, at 15:17, Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> > university.de> wrote:
> > > >
> > > > I guess considering the built-in types as incompatible is the most
> > > > robust approach. If we agree that RFC 7950 tried to say this, we could
> > > > file an errata and propose clearer language.
> > >
> > > Right.  And we can keep the COMI key-to-URL mapping as is, as this
> > clarification is necessary for its correct functioning.
> > >
> > > Grüße, Carsten
> > >
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod