"Rob Wilton \(rwilton\)" <[email protected]> wrote:
>
>
> > -----Original Message-----
> > From: netmod <[email protected]> On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: [email protected]
> > 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
