I don't know where exactly it could be used (programming ?) but I don't think so short abbreviation could be a good idea.

Unless you are an IDMEF expert "s(x).n.a(y).a" is very obscure, and just for "a" in IDMEF there is address, assesment, aditionaldata, analyzertime, etc.

But maybe "longer" abbreviation might be an idea ? (where ?)

CEF is using "key names" with "shorter" name like "src" for "SourceAddress", "shost" for "sourceHostName", etc ... but I don't know yet exactly where they use it.

But then again, only expert can guess that "src" is "SourceAddress" ... and why "source" is abbreviated "src" in "SourceAddress" and only "s" in "sourceHostName" and so on.

G.

I would believe that having an explicit naming structure is better than having a compact one. I would in consequence prefer much more a "source(x).node.address(y).address" than a "s(x).n.a(y).a" notation.

I agree with Gilles and Ludovic. In essence, it significantly reduces the readability of messages. It only is useful for compression, and there are other, more efficient, means to compress XML messages.

You’re right, at first sight the best way would be to use an XML-specific algorithm which assigns individual tags pseudonyms like S for Source or N for Node.
But only at first sight!

Few years ago appears a W3 standard named EXI (Efficient XML Interchange).
EXI = (XML + XMLSchema) as binary.
The problem consists in the fact that XML was born "against" binary...

Is your interrogation dealing with compression?
Another alternative to "compress" XML would be FI (Fast Infoset).
Thus, XML contains every tag and attribute only once, while all other occurrences are referencing the first one (the more there are occurrences the more there is saved space).

Otherwise, maybe can we discuss about JSON?
It drastically reduces the size of the message. Who know more about JSON?
For this topic, see you soon in FORMAT thread... ;-)

Not the Format thread but the TRANSPORT thread where the format is one of the keys...