ietf-xml-mime
[Top] [All Lists]

Re: MIME Type Review Request: image/svg+xml

2004-11-23 11:28:29

On Friday, November 19, 2004, 1:08:27 AM, Martin wrote:


MD> Sorry this is late. Here are some comments on this registration:

MD> - Some of the ideas discussed at
MD>   
MD> http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html
MD>    might help improve the specification.

Thanks, I will take a look.

MD> - The text below was produced by using an HTML-to-text conversion.
MD>    Ideally, it should be possible to use the registration template
MD>    directly as plain text, i.e. the most important URIs should
MD>    appear in plain text.

Thats certainly a possibility. Or the conversion could be trimmed by
hand. i was trying to ensure that exactly the same text was in te W3C
appendix and the registration.

MD> - On the other hand, there is no need to provide URIs for RFCs.
MD>    Something like "... [6]RFC3023 ..."
MD>        [6] http://www.w3.org/TR/SVG12/references
MD>    in an IETF context, is quite confusing.

Yes.

MD> - "Published specification:
MD>           This media type registration is extracted from Appendix G of
MD>           the SVG 1.2 specification."
MD>    This sounds like it's the wrong way round. "Published specification"
MD>    doesn't mean the specification of the registration template, but
MD>    the specification of the format.

Yes this could have ben better worded. I was trying to say "the
published specification is SVG 1.2, of which this registration forms
appendix G.


MD> - Last but not least, I agree with comments already made in this venue
MD>    that this media type should allow the 'charset' parameter as defined
MD>    in RFC 3023. As argued in detail at
MD>    http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html,
MD>    I do not see any way to justify removing the 'charset' parameter

In that case, perhaps you could examine
http://lists.w3.org/Archives/Public/www-tag/2004Oct/0016.html

and argue against the points made there, saying why the approved TAG
findings and the Architecture of the World Wide Web are incorrect.

Its much more productive to fix RFC3023 to not be in conflict with Web
Architecture which (as co-editor) i am involved in doing.

MD> Continuing to allow the 'charset' parameter (or in this case,
MD> putting it back in)

Neither of those are correct. it is not a case of putting it back in,
since it was never there; it is not a case of continuing to allow it,
since it is not there.

MD> will make it easier to use generic tools (both on the producer side
MD> (databases, java servlets,...) and on the client side (xml editors,
MD> validators,...), which is one of the main advantages of +xml.

Actually no. The sole use case for the charset, given that in the
revision of 3023 is required to be the same as what the xml encoding
declaration says, is for *non* xml processors. XML processors will know
how to read and interpret the xml encoding declaration.


  Optional parameters:
         None

         The encoding of an SVG document is determined by the XML
         encoding declaration. This has identical semantics to the
         application/xml media type in the case where the charset
         parameter is omitted, as specified in [6]RFC3023 sections 8.9,
         8.10 and 8.11.

The cases stated there are entirely adequate for robust, interoperable
encoding declaration and are widely, indeed ubiquitously, implemented.
They can confidently be generated by all authoring tools without
knowledge of the precise server configuration.

Your proposal to add a redundant charset parameter merely complicates
server setup, requires authoring tools to be specially configured to
understand server setup, and requires xml instances to be rewritten wen
saved to local disk. All this to benefit *non xml aware* processors
which are going to save to local disk anyway - and if they do, and use
the charset parameter, they still have to understand enough of the xml
syntax to reliably rewrite the encoding declaration. It also results in
xml that is not well formed sitting on the server, making it much harder
to do server side processing.

In conclusion your proposed addition increases complexity, decreases
interoperability, is contrary to existing practice, and provides no
benefit. I thus find it a less than compelling addition.
 
-- 
 Chris Lilley                    mailto:chris(_at_)w3(_dot_)org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group