For me, it seems obvious that we talk about the schema of the instance
data (content). (The other schema defining the format of the instance
data file is fixed and it would be pointless to include it.) Anyway,
we should look at the existing definitions. RFC 8342 defines:
o datastore schema:
I wanted to have an identifier for a particular instance-data-set.
name+revision-date OR timestamp should serve that purpose.
While it would be possible to use this without a name, IMHO that would
be a very bad practice.
Balazs
On 2019. 03. 25. 14:52, Martin Bjorklund wrote:
And a question:
While I agree that target might not be the best name, I want a
name that describes that
"these are the modules I am providing instance data for".
I propose to use the terms:
"content-schema" and "content defining Yang
module(s)" (Sometimes I need to
On 2019. 03. 25. 14:29, Joe Clarke
wrote:
To the point about yang-data-ext/structure, I see instance data was very
useful, but it's a must to be able to augment its metadata. YANG
Catalog would use that. If this draft moves forward without
sx:structure, then I
On 3/25/19 09:52, Martin Bjorklund wrote:
> Joe Clarke wrote:
>> First, I agree with Jürgen that the "target" terminology confused me,
>
> +1
>
>> especially so given you have target-module and inline-target-spec. Like
>> Jürgen and Rob said, "schema" seems to work better.
>
> Since we have
Joe Clarke wrote:
> First, I agree with Jürgen that the "target" terminology confused me,
+1
> especially so given you have target-module and inline-target-spec. Like
> Jürgen and Rob said, "schema" seems to work better.
Since we have "content-data", perhaps use "content-schema"?
And a
First, I agree with Jürgen that the "target" terminology confused me,
especially so given you have target-module and inline-target-spec. Like
Jürgen and Rob said, "schema" seems to work better. And maybe
"inline-schema-module-spec" would be clearer that the spec modifies the
modules from which
