> Maybe it is because I am already seeing the additional code which needs > to be > written when using dedicated xml-nodes for each input type instead of > having > one input XML-tag with a type parameter, which does not necessarily > needs to > be called "type". I have read the comments about using a XML DTD, but > if we > are going to use the format for multiple applications, it could become > difficult to maintain a common version of the XML DTD. > > So the question is, is it that much more human read-/use- able to use > "<imtcp..." instead of "<im type=tcp..." or "<im id=tcp..."?
I still fail to see the issue, maybe I still misunderstand. For all others I'd like to remind that Adiscon is looking for a common format, if possible, for all tools and Andre is concerned about the Windows tools. These do have a static set of entities, so some problems I have with rsyslog simply do not exist there. First of all, we do not necessarily need to validate the XML. And we are discussing on a related thread about using expat in rsyslog, which seems not to have that facility at all. So it looks like something nice to have, but otherwise optional. The "<im type=...>" approach does not provide proper validation in all cases. The "<imtcp ...>" approach does not provide it either, when used with a non-validating parser (but it could be more precisely validated with a validating parser or other XML tools -- not the point here). So from the point of validation, I think they are pretty close. As far as I see the code to be written, it just needs to get information from the parser about the structure of the configuration. For a static entity set, I assume a one-stop "generate DOM" call would be sufficient. For the more dynamic world of rsyslog, we probably need to use SAX-like callbacks. In any case, it is doable. After the config structure is clear, the apps need to interpret it and generate the app-specific actual software objects instances that do the real work. To do so, the "DOM" must be inspected and acted upon. I assume that in this phase a number of semantic checks must also happen (so config load may fail in that phase as well). Again, I don't see a difference in code complexity if we use a) "<im type=..." or b) "<imtcp...". In case a), we need to look at the entity name, in case b), we need to find and look at the type attribute. My uneducated guess is that this is roughly equivalent amount of work to do. In conclusion, I do not see any notable difference in code sizes for both approaches. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com

