
At 7pm on 23/10/03 you (Linus Walleij) wrote:
On Wed, 22 Oct 2003 ben@morrow.me.uk wrote:
Rather, my question is, why are you using XML rather than (say) some format based on short-lines-of- ASCII (perhaps taking RFC2822 as your model)? Given that the data to be represented is pure ascii, and has a very simple structure, do you really need all the complexities of XML?
First, it's an Internet thing we wanna do, so if we were just writing "the most simple hexdump standard" the place to do it would probably be IEEE and not IETF.
This is rather what I was worried about :). I would have said that if you were writing 'the most simple hexdump standard; subject to it being textual, more-or-less human-readable and widely interoperable' then the IETF is exactly the place to do it. For example, RFC2822 is pretty close to 'the most simple email format'. And even MIME, which extends it, is still based on lines of ASCII text. MIME could easily be recast into XML, but there would be no advantage in doing so.
Such de facto-standards (like S-records) already exist. We expect the need for transport of this kind of data to increase, so an IETF RFC is needed.
Of course. And you should of course consider more than your immediate needs when writing such an RFC, as you have done.
Also, if we should not go for XML, then the same line of reasoning about simplicity would also go for BEEP and others, yes?
I don't know...BEEP is not something I am familiar with. Looking over the RFC, BEEP messages seem to have the property that there are a number of different 'classes' of message, each with a fixed internal structure; this list of classes is extensible. This is a data model which XML is well suited to.
These RFCs give me the impression that textual transport should be made in XML where possible, not only where complexity is above some certain level. (Correct med if this is wrong.)
I would have said 1. For a simple format like a hex dump, using XML adds significant complexity. 2. You should not add complexity to a format unless there is a significant advantage in doing so. So the question then is, what advantage is XML giving you?
Perhaps the most important point raised was that if we need to extend this format, e.g. replace it with an SHF v.2 at some point (if not before, then as 128bit computing is introduced sooner or later), XML is easy to extend, version and add structure in, if desired. When complexity increase, XML scales fine.
This is true. However, such things as changing the maximum word size are easy to work into a simple format (indeed, there is no real reason to limit the word size at all beyond the specifics of your hashing mechanism). Other structure I would say would be better dealt with by defining a new format which includes a section of SHF: quite possibly this new format could be XML-based, viz.: <newformat> <metadata value="foo"/> <hexdump type="text/shf"> [here follows an SHF object] </hexdump> </newformat> But this is all just my opinion: if noone else on the list backs me up I will consider myself outvoted and keep quiet :). Ben