Cart
[Home] [By Thread] [By Date] [Recent Entries]
Don, 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. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
