At 2pm on 22/10/03 you (Linus Walleij) wrote:
On Wed, 22 Oct 2003 ben@morrow.me.uk wrote:
Could I write something like:
Second, neither the "xml" processing instruction nor the "DOCTYPE" declaration need to be present.
Ah yes, this is quite different. I ws puzzled by 'neither... MAY be present'.
(Accordingly, if a character set other than UTF-8 is desired, then the "encoding" parameter must be present in an "xml" processing instruction .)
For this, see Chris Lilley's mail. The paragraph he gives is all that is required.
Two additional points: would it not be worth declaring an XML namespace for this format in addition to the DTD?
I have seen no standards for this: there are however two drafts about it, while we don't know if they will be published, we fashined this like e.g. the BEEP standard.
What about <http://www.w3.org/TR/REC-xml-names>? OK, that's W3C not IETF, but they are probably the appropriate standards body wrt XML stuff. This is rather a side issue, and doesn't really matter. :)
and would it not be worth adding support for using hashes other than SHA-1,
We had this discussion, and SHA-1 is sort of IETF standard (RFC 3174).
Sorry. Fair enough. :)
More generally, although this may be out of the remit of this list, is an XML-based format not a little complex for a hex dump?
The main purpose is transport and storage. In reality, dumps are typically not transferred to embedded systems by way of textual formats anyway, instead a host program ("flasher" etc) on some other machine will typically read the SHF file and transfer the data via serial bus in some custom format.
This is not quite my point (although it does clarify that the format would be useful rather than futile :). 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? Ben