The protocol cannot be defined without any knowledge of the data model; i.e. there is a point where the two intersect. This work is being done with assumptions about what the data model will look like -- those assumptions have been implicit (i.e.: in everyone's head they have their view of what the data model will look like).
At some point we need to start to document the intersection. This discussion seems like a good starting point.
So let me reiterate what Bob Moore said... we need to define how instances are identified. Let's move the discussion to how we define the instances and away from the discussion about if we need to define the mechanism for instances.
Regards, /gww
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Tuesday, August 26, 2003 12:04
> To: Phil Shafer
> Cc: Waters, Glenn [CAR:IO47:EXCH]; Paul Sangree; netconf@ops.ietf.org
> Subject: Re: merge/replace selection criteria
>
> At 08:00 AM 8/26/2003, Phil Shafer wrote:
> >"Glenn Waters" writes:
> >>Maybe I missed the answer to this in one of the other posts, but if you
> no
> >>longer use the junos:key="key" to identify the lookup keys then how does
> the
> >>user know what attributes are indices? XML Schema does not provide a
> >>mechanism to identify them.
> >
> >We use the appInfo element to mark them.
>
> what about the <unique> or <key> elements?
>
> In any case, I think this is a data definition issue which is
> outside our charter. We just need to identify the requirement
> that data naming be done in a consistent manner which allows
> for non-ambiguous identification within our protocol operations.
>
>
> >Thanks,
> > Phil
>
> Andy