[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Notification #9: replay in the future consensus point
Sharon Chisholm 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?
I don't consider these meta-data and it is only meta-data that you are
suppose to be using attributes for according to best practice I keep
hearing. These should be elements so I don't think there is an issue.
Leave the <notification> element such that nobody may ever
place an XML attribute there. It can't be part of the filter anyway,
which starts at the next layer.
Note that there is no standard for 'eventClass', 'eventSeverity',
or 'eventTime', and a vendor may choose to use XML attributes
or elements for these fields (if they exist at all).
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.