Here's my suggestions...
Methinks xml:encoding is too close to the XML PI encoding for character
set encodings. I wish that the XML PI encoding had been called
text-encoding or char-encoding -- this would have made it easier to come
up with other 'encoding' attributes without ambiguity. *sigh*
How about:
1. xml:transfer-encoding
2. xml:content-encoding
Suggestion #1 is a little ugly because it has the word 'transfer', but
this is closer to the MIME heritage where base64 is primarily used for
packaging style encoding, as opposed to locale char-set encoding.
Suggestion #2 may seem redundant but at least doesn't conflict directly
with 'encoding' in the context of locale char-set encoding.
As for the mimetype attribute...I'd vote for something closer to IOTP,
such as:
xml:content-format
where content-format can be one of:
- a mimetype that indentifies the content format, e.g. "image/jpeg"
- a user-defined code of the form "x-ddd:nnn", where ddd is a domain and
nnn is an arbitrary name for the format e.g. "x-jetform:mdf"
However, IOTP includes other acceptable values for content-format such
as 'PCDATA' and 'XML'. I view this as duplication and believe that only
the two options above are necessary; i.e. XML content should be able to
be expressed as 'text/xml', ignoring the fact that this isn't a *real*
mimetype.
And I assume that the implication in all of this that somebody could
include content that contains well-formed and valid xml that happens to
be base64'd? Hence it is neccessary for the parser to unwrap such
sections, right?
Thoughts?
Gavin.