Please review application/shf+xml

[ben at morrow.me.uk]

At  7pm on 23/10/03 you (Linus Walleij) wrote:
> On Wed, 22 Oct 2003 ben at 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