[Code Friday] The most useful advice I will ever give anyone.

[maradydd]

Suppose you're designing a protocol, and you're deliberating over whether to use XML, YAML, JSON, s-expressions (!) or some other data representation format for it.

The question you need to ask yourself is, "have I written an EBNF definition for my protocol yet

Comments

[krfsm]

I really really really want a whiteboard at home. It's so handy for working out things! Sadly we don't really have the space for it currently.

[vatine]

I have a large on in the bedroom (sadly, not at a good position to write on it) and a smaller one a few steps from the keyboard. Invaluable for scribbling and testing things "on paper".

[maradydd]

We used to have one on the wall in the living room and one on the wall in the bedroom. Sadly we gave them away before moving, and will need to get more.

I like michiexile's field-expedient solution: whiteboard markers and any mirrored surface.

[vatine]

Plain glass works well too. Never tried it on lexan, but I suspect it'll work well too (use a sacrificial piece, just in case it doesn't).

[steer]

Interesting -- but what does it actually gain you?

Designing the grammar first might mean your grammar is less than well suited to the particular data format you then wish to pick or, indeed, illegal in that format.

Or have I completely missed the point?

I guess, I'm just thinking, if I do the EBNF then I can, for example, immediately rule out XML unless I secretly thought "I'll use XML" then did the EBNF and then decided -- in which case the EBNF case was merely a ponderous waste.

What am I not seeing? I think I *AM* intermingling data representation and protocol structure but I cannot see how NOT to do this using EBNF.

[vatine]

Data structure is part of your code, protocol grammar is part of a transport layer. It MAY be that having a clear 1:1 mapping between data structure and wire protocol is a good thing, but it may also be that it isn't. And don't force me to say "ASN.1", because I will start crying.

[maradydd]

If you're not careful I'm going to start thinking of you as one of my acolytes. ;)

[steer]

Perhaps questions related to specifics might make it clearer for me. I am thinking of an example where, say, I am designing the allowable layout of a config file for a simulation (read in at start up, generates parameters for simulation, somehow translated into a data structure internally). This affects data structure but is not data structure, it's a protocol.

I guess my methodology would be to pick (say) XML, design the grammar to work in XML (using one of the XML definition thingums) with an eye on the eventual data structure in the code but not genuinely dictated by that. What do I gain by adding EBNF because it seems there is a lot to lose?

[wetdryvac]

*grins*

Ooo, stuff I've not dug into before. Fun!

*dives in*

Thank-you.

[feonixrift]

It's apparent to me that this is a good idea, but I'm having difficulty pinpointing the reasons.

[m4dh4tt3r]

Sound advice. I gather this came out of the discussion with Jake about what he should use to represent the data format for his most recent project.

[maradydd]

Yup. It occurred to me that various people, Jake included, have heard me go off on this subject repeatedly, but that I haven't really talked about it much here.

enochsmiles has finally browbeaten me into getting all my thoughts in order on the subject of language-theoretic security in general, to the end that we're now putting together a journal article on it. God knows how long that'll take, but it'll make his advisor happy.