Hello Mike Thanks for your input. I've answered your concerns below:
>> I don't like the tag "event". I think it should be <log> tag instead, >> no to confuse anybody. I have made several custom XMPP components and >> client where they have event tag embedded, which have a completely >> different meaning and context. > >I also think that "event" is a bit too broad of a term here and would prefer >"log" or even "eventlog" Yes, this was confusing. I've changed it to <log> now. I'll send an updated version shortly. >> Type and Level? I think its too complicated. Only level should be >> present and with fewer clases.. Debug, Info, Notice... is way too much. >> People tend to misuse and not think when they have a lot of choices. >> :-) > >I also think that this may be too many options and would prefer to see Level >limited to a smaller set and have Type removed completely as it could be >implemented as Tags. I've chosen to make them optional, since I understood they will not be used in all cases, to reduce complexity. However, in larger systems they are very important. As I mentioned in a previous mail, the Type's actually come from Syslog classification of events. One of the main points was to easily map Syslog events on-top of what we currently define. Tags are fine, but too loose to become an effective standardized way to qualify an event. You need something a little bit more rigid controlled by a schema to enforce some kind framework for broad categorization. That was the idea anyway. The attributes are optional, so you can send events without them. They become minor informational events in that case. >I do love that you've chosen to use words instead of numbers to represent the >levels. Thanks. Sometimes fuzzy logic beats exact numbers when it comes to reasoning. (Married people will know what I mean.) > Another item I wanted to bring up is can we just remove timezone worries > completely and say "use UTC and only UTC"? IMO it is a best practice and > would avoid the whole TZ issue (yea, yea, I know this one is going to be a > long shot ;) That might sound like a good idea, but I hesitate. Why? On modern PCs, this is not a problem, since they have a time zone defined in the operating system, and conversion between local time, standard time and universal coordinated time is easy. But in small devices it is not so. They are seldom aware of the current time zone, and sometimes not even of daylight savings time. In these cases it would be hard, perhaps practically impossible, to provide correct time zone information. Having said that, I agree that simplifying XEP-0082 so that it only used UTC when representing time zones would be a great bonus. Best regards, Peter Waher
