Hello Dave
Thanks for your input. I'll try to respond as best I can:
>FWIW, I have a considerable preference for "event" over "log". A log is a
>permanent record of events, and you'll note that the literature on logging
>refers to events...
Yes, the noun log is a log of events. However, log is also a verb, to log
something (in a log book for instance). This is how I saw it. My first version
used event, for the reason you mentioned. However, Steffens argument that there
are so many kinds of "events" made me think twice. And there will be yet
another type of event not yet sent to the XSF relating to IoT events (i.e.
"tell me when the temperature reaches 20 degrees Celcius so I can ..." (turn
off heater for instance)).
I'm still open to what name we use. I'm fine with log (and event). I'd let the
council decide.
> ...In fact, the protoXEP uses that term of art throughout.
Not sure what you mean by this. Is it a question or something I should correct?
Or an argument for what you wrote previously?
>Second, I think the "message" attribute should be a child element, with the
>message as content.
Can change that if it is the council's decision.
It has one advantage, but also one weakness. The advantage obviously is that it
is easier to write. The weakness is that indentation might be a problem if you
use indentation in your examples for multi-line messages. Attributes are
clearer in this regard since you're forced to think about it. I also wanted to
drop subelements (see explanation below)
>I think what's needed overall is to map RFC 5424 into XML, and allow extension
>in roughly the same way that we extend stanza and stream errors. So what you'd
>get would be the RFC 5424 HEADER construct as a containing event element, and
>it would contain detail as either a <structured/> element with a sd-id
>attribute, or a <message/> element.
I wanted to avoid sub-elements at all to allow for very simple messages to be
sent. The point was to allow for both simple messages (almost as simple as
simple text messages) but still allow for more complexed logging, type Syslog.
I see no value in structuring information into sub-elements by itself. It
doesn't make it easier to write and it doesn't make it easier to parse. And it
does not provide additional information.
>I'd personally drop in facility and severity into the event element itself,
>because virtually everything uses those instead of PRI, but still.
>
>The result looks roughly like:
>
><event lots-of-attributes>
> { <message>A message here</message> | <structured
> sd-id='horrible-syntax@12345'><param name='foo'>Value</param></structured> }
></event>
Not sure what to comment.
> As far as transport, I really think that any logging source ought to expose
> itself as XEP-0060, but I could be wrong there.
Yes, I know some would like to use pubsub. However, the extension is not
limited in this regard. Many would think events are or should be considered
sensitive information and therefore not published. They would use directed
messages to an event sink. Others might disagree, and they could publish the
events using pubsub. It must be an implementation issue I believe.
Do you think it is necessary to explicitly write an explanation about this into
the XEP? If yes, including examples, or a simple textual description as the one
above would be sufficient?
Best regards,
Peter Waher
