headers
Bjoern Hoehrmann | 1 Nov 2004 02:49
Picon

SVG12: charset parameter for image/svg+xml

Dear Scalable Vector Graphics Working Group,

  http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
register the "image/svg+xml" MIME Type but the registration lacks the
charset parameter as defined in RFC 3023. This defeats the purpose of
the +xml convention which attempts to provide a means for generic XML
processing.

Generic XML tools such as Validators, Editors, XSLT and XQuery
processors, and full-text XML search engines would need to maintain
special knowledge to ignore the charset parameter for image/svg+xml
documents which is expensive and unlikely to happen. In fact, a number
of deployed tools already don't do that, for example the W3C Markup
Validator would need to be updated with special code for image/svg+xml
in order to comply with the registration.

Thus, please change the registration to be consistent with application/
xml as defined in RFC 3023.

regards.
Permalink | Reply | 0 comments |
headers
Jim Ley | 1 Nov 2004 03:58

Re: SVG12: charset parameter for image/svg+xml


"Bjoern Hoehrmann" <derhoermi <at> gmx.net> wrote in message 
news:41b49119.563677485 <at> smtp.bjoern.hoehrmann.de...
>  http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
> register the "image/svg+xml" MIME Type but the registration lacks the
> charset parameter as defined in RFC 3023. This defeats the purpose of
> the +xml convention which attempts to provide a means for generic XML
> processing.
>
> Thus, please change the registration to be consistent with application/
> xml as defined in RFC 3023.

I fully agree with this, I would also like the Working Group to consider 
registering application/svg+xml with a distinction between image and 
application being scripting and sXBL within the document.  The reasons, I've 
raised before, but if you want me to elaborate further, I can do.

Cheers.

Jim.
Permalink | Reply | 0 comments |
headers
iana | 1 Nov 2004 04:56
Favicon

ConfirmSystem: iana <at> icann.org [[ca7128ef62ae0fe9]]

Thank you for your message.

The iana <at> iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=ca7128ef62ae0fe9&l=iana <at> icann.org>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Re:"

and it arrived at IANA approximately at Sun Oct 31 19:56:37 2004.

---------------------------------------------------------------
ConfirmSystem: iana <at> icann.org [[ca7128ef62ae0fe9]]
1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Lilley | 1 Nov 2004 20:03
Picon
Favicon

Re: SVG12: charset parameter for image/svg+xml

On Monday, November 1, 2004, 2:49:32 AM, Bjoern wrote:

BH> Dear Scalable Vector Graphics Working Group,

BH>   http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
BH> register the "image/svg+xml" MIME Type but the registration lacks the
BH> charset parameter as defined in RFC 3023. This defeats the purpose of
BH> the +xml convention which attempts to provide a means for generic XML
BH> processing.

On the contrary! The +xml convention clearly indicates, for an unknown
media type, that it is xml; thus, that an XML processor should be used;
which will correctly determine the encoding from the xml encoding
declaration or lack therof.

I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
agreed that the +xml convention, plus the deprecation of text/xml and
associated charset handling weirdness of required us-ascii fallback,
allows consistent handling

BH> Generic XML tools such as Validators, Editors, XSLT and XQuery
BH> processors, and full-text XML search engines would need to maintain
BH> special knowledge to ignore the charset parameter for image/svg+xml
BH> documents

No, they would not. RFC 3023 already allows the charset to be omitted,
and gives rules to follow for this case. SVG follows those rules, as the
registration document makes plain.

However, if such a parameter were to be added, anything that downloaded
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Hoehrmann | 1 Nov 2004 21:14
Picon

Re: SVG12: charset parameter for image/svg+xml

* Chris Lilley wrote:
>BH>  which is expensive and unlikely to happen. In fact, a number
>BH> of deployed tools already don't do that, for example the W3C Markup
>BH> Validator would need to be updated with special code for image/svg+xml
>BH> in order to comply with the registration.
>
>Incorrect; see above.

The W3C Markup Validator considers resources such as

  Content-Type: image/svg+xml;charset=iso-8859-1

  <?xml version='1.0' encoding='utf-8'?>
  ...

ISO-8859-1 encoded. If it is incorrect that the W3C Markup Validator
needs to change you either want that all processors treat the resource
ISO-8859-1 encoded in which case there is not really a point in not
allowing an optional charset parameter, or you want two classes of non-
interoperable processors, where some consider it ISO-8859-1 and others
consider it UTF-8. Which one is it?
Permalink | Reply | 0 comments |
headers
Chris Lilley | 1 Nov 2004 21:39
Picon
Favicon

Re: SVG12: charset parameter for image/svg+xml

On Monday, November 1, 2004, 9:14:02 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH>  which is expensive and unlikely to happen. In fact, a number
>>BH> of deployed tools already don't do that, for example the W3C Markup
>>BH> Validator would need to be updated with special code for image/svg+xml
>>BH> in order to comply with the registration.
>>
>>Incorrect; see above.

BH> The W3C Markup Validator considers resources such as

BH>   Content-Type: image/svg+xml;charset=iso-8859-1

BH>   <?xml version='1.0' encoding='utf-8'?>
BH>   ...

BH> ISO-8859-1 encoded.

Yes, there are two inconsistent pieces of metadata and the markup
validator correctly applies the rules to determine which to use. Note
that the example above, if saved to disk and re-opened, is not well
formed. This is undesirable. Lots of content is processed from local
disk, on servers and on clients.

The markup validator does the correct thing also in this case

Content-Type: image/svg+xml

  <?xml version='1.0' encoding='utf-8'?>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Lilley | 1 Nov 2004 22:02
Picon
Favicon

Re: SVG12: charset parameter for image/svg+xml

On Monday, November 1, 2004, 9:46:15 PM, Boris wrote:

BZ> Chris Lilley wrote:
>> On the contrary! The +xml convention clearly indicates, for an unknown
>> media type, that it is xml; thus, that an XML processor should be used;
>> which will correctly determine the encoding from the xml encoding
>> declaration or lack therof.

BZ> I think the concern was about what happens when someone sends the 
BZ> following HTTP header:

BZ>    Content-Type:  image/svg+xml; charset=iso-8859-1

BZ> combined with an XML document that has no encoding declaration (so 
BZ> defaulting to UTF-8).

That is (for a random +xml media type) currently allowed. It is, as you
say, a problem. (It defaults to UTF-8 or UTF-16 depending on the
presence of absence of a BOM and, if present, what bytes represent it).

BZ> Now per the type registration for "image/svg+xml", the above 
BZ> Content-Type header is invalid, right?

Yes. Instead of an optional parameter which should not be used and if
used, causes problems, the proposal is to not have the parameter.

BZ>  So what's a UA to do?  What encoding to use?

Under which rules? Currently, that is a malformed document that has been
temporarily made well formed while in transit. If saved, it needs to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Hoehrmann | 1 Nov 2004 22:19
Picon

Re: SVG12: charset parameter for image/svg+xml

* Chris Lilley wrote:
>BH> The W3C Markup Validator considers resources such as
>
>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>
>BH>   <?xml version='1.0' encoding='utf-8'?>
>BH>   ...
>
>BH> ISO-8859-1 encoded.
>
>Yes, there are two inconsistent pieces of metadata and the markup
>validator correctly applies the rules to determine which to use.

What makes you think there is inconsistent metadata here? The
charset parameter in the example above has no semantics that
could be inconsistent with other information.
Permalink | Reply | 0 comments |
headers
Chris Lilley | 1 Nov 2004 22:35
Picon
Favicon

Re: SVG12: charset parameter for image/svg+xml

On Monday, November 1, 2004, 10:19:01 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> The W3C Markup Validator considers resources such as
>>
>>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>>
>>BH>   <?xml version='1.0' encoding='utf-8'?>
>>BH>   ...
>>
>>BH> ISO-8859-1 encoded.
>>
>>Yes, there are two inconsistent pieces of metadata and the markup
>>validator correctly applies the rules to determine which to use.

BH> What makes you think there is inconsistent metadata here?

The encoding is declared in two places, and they are different. One is
the charset parameter, and one is the xml encoding declaration.

BH> The charset parameter in the example above has no semantics that
BH> could be inconsistent with other information.

Its clearly inconsistent! The encoding declaration has the same
semantic. It agree that there is a mechanism to *resolve* the ambiguity,
but the inconsistency is clearly there.

--

-- 
 Chris Lilley                    mailto:chris <at> w3.org
 Chair, W3C SVG Working Group
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Hoehrmann | 1 Nov 2004 22:41
Picon

Re: SVG12: charset parameter for image/svg+xml

* Chris Lilley wrote:
>>>BH> The W3C Markup Validator considers resources such as
>>>
>>>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>>>
>>>BH>   <?xml version='1.0' encoding='utf-8'?>
>>>BH>   ...
>>>
>>>BH> ISO-8859-1 encoded.
>>>
>>>Yes, there are two inconsistent pieces of metadata and the markup
>>>validator correctly applies the rules to determine which to use.
>
>BH> What makes you think there is inconsistent metadata here?
>
>The encoding is declared in two places, and they are different. One is
>the charset parameter, and one is the xml encoding declaration.

Why does the charset parameter in the example above declare an encoding?
>From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
be clear that the is no charset parameter and it thus cannot have such
semantics, so there is no inconsistency here.
Permalink | Reply | 0 comments |

Gmane