Lists Home |
Date Index |
- From: Gavin McKenzie <gmckenzi@JetForm.com>
- To: 'Don Park' <firstname.lastname@example.org>, "'email@example.com'" <firstname.lastname@example.org>
- Date: Mon, 9 Feb 1998 09:14:00 -0500
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*
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,
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*
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
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)