Balazs Lengyel wrote:
Hello,As we see it 'eventClass', 'eventSeverity','eventTime' and 'eventSender' are not meta-data but real data, they are essential and mandatory parts of every notification. I would really prefer them as elements instead of attributes. I can even foresee someone extending eventClass with a vendor specific evntSubClass.
Think about this statement. If a vendor was to extend the standard definitions, they would no longer be standard. From an XML-PoV, these extensions belong in the standard or vendor-defined <eventType>, in a different namespace. The value of 'fixed' standard fields is that they are fixed, and a manager can count on them meaning what they are supposed to mean across all agent implementations. Andy
On the other hand extensibility is good, so an anyAttribute does no harm. Balazs Andy Bierman wrote:The 'eventClass', 'eventSeverity', and 'eventTime' fields are meta-data which could be encoded as XML attributes in the <notification> element. This should be required, even if the proprietary <eventType> has some or all of these fields already. This is why I keep asking the WG: Are you SURE you want to forbid all XML attributes, forever, from being included in the <notification> element? Are you SURE this is not going to ever come up again as an issue, because this is the only place we can really put inter-operable meta-data into the notification message? (All we need is an 'anyAttribute' clause in the <element> definition...)
-- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>