Subject: practical question
From: Lucas Gonze <[email-masked]>
To: [email-masked]
Date: Wed, 23 May 2007 15:20:31 -1000 (HST)
List-Id: <ietf-xml-mime.imc.org>

This is a practical question related to application/foo+xml media types. 
I recognize that this is not a programming forum; I am posting here anyway 
because I think that this group will be keenly aware of the problem and 
interested in a solution.

IE will only allow cross-domain requests for the text/xml or 
application/xml types.  It does not support application/foo+xml.

Does anyone know of a workaround which would allow me to avoid having to 
publish resources with the wrong (application/xml) type?  If I do have to 
publish with the wrong type, does anyone know of a method which would 
allow me to minimize the damage?

This is important because it is a limiting factor for all XML-based 
formats.

Thank you.

-Lucas Gonze

From: "Larry Masinter" <[email-masked]>
To: "'Chris Lilley'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>
Cc: "'Dave Singer'" <[email-masked]>, "'Martin Duerst'" <[email-masked]>, "'Anne van Kesteren'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Christian Timmerer \(ITEC\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: MPEG asks for MIME review for the MPEG21 file format
Date: Tue, 22 May 2007 18:24:14 -0700
Sender: [email-masked]

I'm really sorry to have opened this rat-hole on multiple mailing lists. I
suggest
moving the discussion of the hypothetical potential future possible
proposals from 
the W3C XML efficient encoding group --- if you want to continue it at all
---
to [email-masked] (I think that's the most appropriate) 
and removing any  other cc's.

Thanks,

Larry

Date: Tue, 22 May 2007 18:45:00 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Graham Klyne <[email-masked]>
Cc: Dave Singer <[email-masked]>, Martin Duerst <[email-masked]>, Anne van Kesteren <[email-masked]>, Larry Masinter <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Monday, May 21, 2007, 6:24:33 PM, Graham wrote:

GK> Chris Lilley wrote:
>> On Monday, May 21, 2007, 11:13:58 AM, Graham wrote:
>> GK> For clarification: this would be the case only when a suitable MIME
>> GK> content-transfer-encoding header is applied, n'est pas? 

>> If its compressed on the fly, yes. If its stored compressed on the server, then Content-Encoding is used.

GK> Ah, I hadn't considered Content-encoding here.

GK> I note that this header is defined by RFC2616 and registered only for use with
GK> HTTP
GK> (http://www.iana.org/assignments/message-headers/perm-headers.html), which
GK> suggests that it is defined only as part of an HTTP protocol transfer.

Yes, I was talking of HTTP here.

Clearly if one uses, for example, FTP then that isn't an option. But then, neither is the Internet Media type :)

GK> #g

GK> (being rather language-lawyer-ish at this point?)

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Tue, 22 May 2007 18:44:10 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: "Anne van Kesteren" <[email-masked]>
Cc: "Larry Masinter" <[email-masked]>, "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Monday, May 21, 2007, 6:37:32 PM, Anne wrote:

AvK> On Mon, 21 May 2007 17:24:33 +0200, Chris Lilley <[email-masked]> wrote:
>> AvK (Assuming you meant charset="blah" as
>> AvK> opposed to encoding="blah" above given your examples of UTF-8 and
>> AvK> UTF-16...)

>> No, I meant exactly what I typed.
>> http://www.w3.org/TR/xml/#NT-EncodingDecl

AvK> Oh, right. They'll make the XML declaration mandatory?

Its already mandatory if you use any encoding other than UTF-8 or UTF-16.

AvK>  I actually thought
AvK> this was about being able to reject it at the HTTP level.

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Mon, 21 May 2007 18:37:32 +0200
To: "Chris Lilley" <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
From: "Anne van Kesteren" <[email-masked]>
Organization: Opera Software
Cc: "Larry Masinter" <[email-masked]>, "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 21 May 2007 17:24:33 +0200, Chris Lilley <[email-masked]> wrote:
> AvK (Assuming you meant charset="blah" as
> AvK> opposed to encoding="blah" above given your examples of UTF-8 and
> AvK> UTF-16...)
>
> No, I meant exactly what I typed.
> http://www.w3.org/TR/xml/#NT-EncodingDecl

Oh, right. They'll make the XML declaration mandatory? I actually thought  
this was about being able to reject it at the HTTP level.

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Date: Mon, 21 May 2007 17:24:33 +0100
From: Graham Klyne <[email-masked]>
To: Chris Lilley <[email-masked]>
CC: Dave Singer <[email-masked]>, Martin Duerst <[email-masked]>, Anne van Kesteren <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

Chris Lilley wrote:
> On Monday, May 21, 2007, 11:13:58 AM, Graham wrote:
> GK> For clarification: this would be the case only when a suitable MIME
> GK> content-transfer-encoding header is applied, n'est pas? 
> 
> If its compressed on the fly, yes. If its stored compressed on the server, then Content-Encoding is used.

Ah, I hadn't considered Content-encoding here.

I note that this header is defined by RFC2616 and registered only for use with
HTTP (http://www.iana.org/assignments/message-headers/perm-headers.html), which
suggests that it is defined only as part of an HTTP protocol transfer.

#g

(being rather language-lawyer-ish at this point?)

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Date: Mon, 21 May 2007 17:26:03 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Graham Klyne <[email-masked]>
Cc: Dave Singer <[email-masked]>, Martin Duerst <[email-masked]>, Anne van Kesteren <[email-masked]>, Larry Masinter <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Monday, May 21, 2007, 11:13:58 AM, Graham wrote:

GK> Chris Lilley wrote:
>> On Friday, May 18, 2007, 5:27:52 PM, Dave wrote:

>> (I'm snipping the parts already covered by Martin)

>> DS> Is a ZIP compressed XML file servable under a +xml MIME type? 
>> DS> "encoding='zipped Shift_JIS'"?

>> I suspect you mean gzip, which is a compression method; zip is an archive format (often compressed internally).

>> If you started with foo.xml in Shift_JIS, the encoding declaration would say just that. If you then make foo.xml.gz the encoding declaration (when decompressed) says exactly the same thing. The fact that is been gzipped is conveyed out of band, in the http headers:

>> Content-Encoding: gzip

>> There is scope for confusion, since XML uses 'encoding' for 'character encoding' (although that's a big advance on calling it 'charset'). HTTP uses content-encoding. The two uses of the concept 'encoding' occur at different levels in the stack.

>> In consequence, using gzip content-encoding is compatible with +xml media types.

GK> For clarification: this would be the case only when a suitable MIME
GK> content-transfer-encoding header is applied, n'est pas? 

If its compressed on the fly, yes. If its stored compressed on the server, then Content-Encoding is used.

GK>  Otherwise such added
GK> encoding/decoding could be applied lower in the stack and not visible at the
GK> level of the MIME object.

GK> #g

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Mon, 21 May 2007 17:24:33 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: "Anne van Kesteren" <[email-masked]>
Cc: "Larry Masinter" <[email-masked]>, "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Monday, May 21, 2007, 10:48:49 AM, Anne wrote:

AvK> On Sun, 20 May 2007 02:24:11 +0200, Chris Lilley <[email-masked]> wrote:
>> Swapping your sentences around: yes, the whole idea of +xml is that you  
>> know you can use a generic XML parser.

>> Something that might or might not be xml, therefore should not use +xml.

>> An XML parser must understand UTF-8 and UTF-16 and may understand other  
>> encodings. I gather that the Efficient XML folks will declare a new  
>> encoding, and parsers which don't know it will not parse it. Same is if  
>> I said the encoding was

>> encoding="i-bet-you-never-heard-of-this-one"

AvK> "Efficient XML" seems to be more on the content encoding level than the
AvK> character encoding level to me.

I would have thought so too, but Liam Quin tells me this is not the current thinking in the EXI WG.

AvK (Assuming you meant charset="blah" as
AvK> opposed to encoding="blah" above given your examples of UTF-8 and  
AvK> UTF-16...)

No, I meant exactly what I typed.
http://www.w3.org/TR/xml/#NT-EncodingDecl

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Mon, 21 May 2007 19:30:23 +0900
To: "Anne van Kesteren" <[email-masked]>, "Chris Lilley" <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Cc: Larry Masinter <[email-masked]>, "'Graham Klyne'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, "'Dave Singer'" <[email-masked]>
Sender: [email-masked]

At 17:48 07/05/21, Anne van Kesteren wrote:

>"Efficient XML" seems to be more on the content encoding level than the  
>character encoding level to me. (Assuming you meant charset="blah" as  
>opposed to encoding="blah" above given your examples of UTF-8 and  
>UTF-16...)

That's not only you. It seems so to virtually everybody.
That's no surprise, because it IS at that level.
The trick is that it can be handled as if it were a character
encoding. That's where the language lawyers come in.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

Date: Mon, 21 May 2007 10:13:58 +0100
From: Graham Klyne <[email-masked]>
To: Chris Lilley <[email-masked]>
CC: Dave Singer <[email-masked]>, Martin Duerst <[email-masked]>, Anne van Kesteren <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

Chris Lilley wrote:
> On Friday, May 18, 2007, 5:27:52 PM, Dave wrote:
> 
> (I'm snipping the parts already covered by Martin)
> 
> DS> Is a ZIP compressed XML file servable under a +xml MIME type? 
> DS> "encoding='zipped Shift_JIS'"?
> 
> I suspect you mean gzip, which is a compression method; zip is an archive format (often compressed internally).
> 
> If you started with foo.xml in Shift_JIS, the encoding declaration would say just that. If you then make foo.xml.gz the encoding declaration (when decompressed) says exactly the same thing. The fact that is been gzipped is conveyed out of band, in the http headers:
> 
> Content-Encoding: gzip
> 
> There is scope for confusion, since XML uses 'encoding' for 'character encoding' (although that's a big advance on calling it 'charset'). HTTP uses content-encoding. The two uses of the concept 'encoding' occur at different levels in the stack.
> 
> In consequence, using gzip content-encoding is compatible with +xml media types.

For clarification: this would be the case only when a suitable MIME
content-transfer-encoding header is applied, n'est pas?  Otherwise such added
encoding/decoding could be applied lower in the stack and not visible at the
level of the MIME object.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Date: Mon, 21 May 2007 10:48:49 +0200
To: "Chris Lilley" <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
From: "Anne van Kesteren" <[email-masked]>
Organization: Opera Software
Cc: "Larry Masinter" <[email-masked]>, "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Sun, 20 May 2007 02:24:11 +0200, Chris Lilley <[email-masked]> wrote:
> Swapping your sentences around: yes, the whole idea of +xml is that you  
> know you can use a generic XML parser.
>
> Something that might or might not be xml, therefore should not use +xml.
>
> An XML parser must understand UTF-8 and UTF-16 and may understand other  
> encodings. I gather that the Efficient XML folks will declare a new  
> encoding, and parsers which don't know it will not parse it. Same is if  
> I said the encoding was
>
> encoding="i-bet-you-never-heard-of-this-one"

"Efficient XML" seems to be more on the content encoding level than the  
character encoding level to me. (Assuming you meant charset="blah" as  
opposed to encoding="blah" above given your examples of UTF-8 and  
UTF-16...)

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Date: Sun, 20 May 2007 02:34:50 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Dave Singer <[email-masked]>
Cc: Martin Duerst <[email-masked]>, Anne van Kesteren <[email-masked]>, Larry Masinter <[email-masked]>, <[email-masked]>, "'Graham Klyne'" <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Friday, May 18, 2007, 5:27:52 PM, Dave wrote:

(I'm snipping the parts already covered by Martin)

DS> Is a ZIP compressed XML file servable under a +xml MIME type? 
DS> "encoding='zipped Shift_JIS'"?

I suspect you mean gzip, which is a compression method; zip is an archive format (often compressed internally).

If you started with foo.xml in Shift_JIS, the encoding declaration would say just that. If you then make foo.xml.gz the encoding declaration (when decompressed) says exactly the same thing. The fact that is been gzipped is conveyed out of band, in the http headers:

Content-Encoding: gzip

There is scope for confusion, since XML uses 'encoding' for 'character encoding' (although that's a big advance on calling it 'charset'). HTTP uses content-encoding. The two uses of the concept 'encoding' occur at different levels in the stack.

In consequence, using gzip content-encoding is compatible with +xml media types.

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Sun, 20 May 2007 02:24:11 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: "Anne van Kesteren" <[email-masked]>
Cc: "Larry Masinter" <[email-masked]>, "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Friday, May 18, 2007, 7:54:32 AM, Anne wrote:

AvK> On Fri, 18 May 2007 03:12:09 +0200, Chris Lilley <[email-masked]> wrote:
>> The successor to RFC 3023 needs to indicate that binary XML which is  
>> presented as a new encoding (in the xml sense) can use +xml, while other  
>> binary forms cannot.

AvK> You wouldn't be able to still parse the retrieved resource in that case
AvK> with a generic XML parser. Wasn't that the whole idea of +xml?

Swapping your sentences around: yes, the whole idea of +xml is that you know you can use a generic XML parser.

Something that might or might not be xml, therefore should not use +xml.

An XML parser must understand UTF-8 and UTF-16 and may understand other encodings. I gather that the Efficient XML folks will declare a new encoding, and parsers which don't know it will not parse it. Same is if I said the encoding was

encoding="i-bet-you-never-heard-of-this-one"

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Sat, 19 May 2007 09:59:51 +0900
To: Dave Singer <[email-masked]>, Anne van Kesteren <[email-masked]>, Chris Lilley <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Cc: "'Graham Klyne'" <[email-masked]>, [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hello Dave,

Some very good questions.

At 00:27 07/05/19, Dave Singer wrote:
>For a lot of these encodings, of course, the initial string is identical (all the ones which have an 'ascii' core).  UTF-16 uses twice the bytes etc.
>
>But in general, given a MIME type with a "+xml" suffix, an XML reader should be prepared to do what?

At the minimum, handle it if it's UTF-8 or UTF-16 (with BOM in the later
case). Everything else is optional.

>I think I am reading "treat the resource as being, in turn, all the encodings you know of, and if you treat it as an encoding, do you find a confirming "encoding" attribute?"

My reading of Appendix F of the XML Spec would be somewhat different.
(See http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info.)
First, it's not character encodings, but character encoding families,
that you try. This makes this process quite a bit faster.

Second, that appendix gives a list of character encoding families.
As the appendix is non-normative, it doesn't necessary exclude
other character encoding families, but there aren't really any other
character encoding families that I know of.

>Which means that encoding='EBCDIC' (I made that up, by the way) would work?

You didn't have to make that up. EBCDIC as a family is listed in said
appendix. The IETF charset registry lists close to 50 EBCDIC variants
(see http://www.iana.org/assignments/character-sets). I guess that
for the 'original' EBCDIC, you'd have to write encoding='EBCDIC-US'.

>Is a ZIP compressed XML file servable under a +xml MIME type? "encoding='zipped Shift_JIS'"?

First, the encoding names allowed in the XML spec don't permit spaces
(see http://www.w3.org/TR/REC-xml/#NT-EncName), but that's a detail.

Second, I'm not familliar with ZIP encoding, but I guess that it's
not starting with any of the byte sequences mentioned in Appendix F.

The third point is that ZIP files are archives, not compressions of
single files. So you would have to restrict this kind of thing to
archives containing single files.

Fourth, ZIP files don't have any way to identify internal character
encodings. And polluting the charset space with zipped_foo,
zipped_bar, ... does not look like a good idea.

>'Semantic' encodings (e.g. MPEG BiM, which uses the schema to be able to compact the XML) are even greyer;  the 'encoding=' is inserted by the BiM decoder, so what does it say then?  I think the 'sanity check' has to be not that the resulting 'encoding=' says BiM, but that the BiM decode worked;  it makes noi sense for the BiM decoder to produce a text document that says "encoding='BiM'"!

Well, actually this is less of a problem. Or put it another way round,
it's a problem that turns up with simple plain old character encodings.
The easiest way to understand this is to think in terms of Java, because
Java has a very clear distinction between byte sequences (Streams) and
character sequences (Readers/Writers).

The whole encoding stuff is important as long as you are on the byte
level. Once the decoding is done, you have external information about
the encoding (in Java, you know it's UTF-16), so the encoding
pseudo-attribute in the XML declaration becomes irrelevant.
That's how the implementations I know handle this, you can hand
an XML document from a Reader or a String to a Java XML parser,
and the characters in there might read:  encoding='shift_jis',
but that's just ignored. There is not too much in the spec
that defines this explicitly, but it's pretty difficult to do
otherwise.

>This is all well off-topic for MPEG-21 of course, but by exploring these edge cases we might get some clarity on +xml, which would be a Good Thing.

Yes indeed. Thanks a lot.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

Cc: "C. M. Sperberg-McQueen" <[email-masked]>, "Anne van Kesteren" <[email-masked]>, "Chris Lilley" <[email-masked]>, "Larry Masinter" <[email-masked]>, [email-masked], "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
From: "C. M. Sperberg-McQueen" <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Date: Fri, 18 May 2007 15:27:05 +0200
To: Martin Duerst <[email-masked]>
Sender: [email-masked]

On 18 May 2007, at 13:07 , Martin Duerst wrote:
>
> At 14:54 07/05/18, Anne van Kesteren wrote:
>> ...
>> You wouldn't be able to still parse the retrieved resource in that  
>> case
>> with a generic XML parser. Wasn't that the whole idea of +xml?
>
> Well, yes, but the language lawyers argue as follows:
>
> Except for UTF-8 and UTF-16, there is absolutely no guarantee
> that an XML parser accepts any encoding whatsoever. There is
> a lot of XML out there with e.g.
>    <?xml version='1.0' encoding='Shift_JIS'?>
> but no XML parser is required to grok that (although many do).
> So you can view binary XML just as an extremely weird and special
> character encoding. I personally wish it wouldn't be necessary,
> but there are people who claim that it is, for whatever it's worth.

First, I agree with Martin's analysis, or rather with his
resumé of the language lawyers' view.

Second, I wonder: Martin, can you clarify something?  When you
say "I personally wish it wouldn't be necessary", do you mean
"I personally wish that it were proven and accepted that the
socalled 'binary XML' format(s) were unnecessary"?  or do you
mean "I personally wish that the language lawyers would not be
such idiots, and that it were generally accepted that this
particular view of "character encoding", and this particular
use of the XML encoding declaration, is unnecessary, and that
binary XML formats should not need to pretend to be
"character encodings" in the sense of the XML specification?

Michael

Date: Fri, 18 May 2007 20:07:29 +0900
To: "Anne van Kesteren" <[email-masked]>, "Chris Lilley" <[email-masked]>, "Larry Masinter" <[email-masked]>, [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Cc: "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 14:54 07/05/18, Anne van Kesteren wrote:
>
>On Fri, 18 May 2007 03:12:09 +0200, Chris Lilley <[email-masked]> wrote:
>> The successor to RFC 3023 needs to indicate that binary XML which is  
>> presented as a new encoding (in the xml sense) can use +xml, while other  
>> binary forms cannot.
>
>You wouldn't be able to still parse the retrieved resource in that case  
>with a generic XML parser. Wasn't that the whole idea of +xml?

Well, yes, but the language lawyers argue as follows:

Except for UTF-8 and UTF-16, there is absolutely no guarantee
that an XML parser accepts any encoding whatsoever. There is
a lot of XML out there with e.g.
   <?xml version='1.0' encoding='Shift_JIS'?>
but no XML parser is required to grok that (although many do).
So you can view binary XML just as an extremely weird and special
character encoding. I personally wish it wouldn't be necessary,
but there are people who claim that it is, for whatever it's worth.

The successor of RFC 3032 shouldn't mention binary XML explicitly
(except by example), but just say that the boundary between what's
okay and what's not okay for a +xml prefix is whether the document
starts as an XML document as described in appendix F of the XML
Rec, and can correctly be parsed after the conversion from that
'character' encoding to XML.

What I also would like to see (in particular in my role as
one of the IETF charset reviewers) is how to make sure that
the labels for binary encodings won't in the future collide
with real registered charsets. Probably the best way to do
this would be to create some kind of 'provisional' registration,
or 'reserving' registration in the charset registry.
But that would need some work on a spec, at the moment,
probably the best way to do things would be to try and
get some kind of comment into the charset registry.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

Date: Fri, 18 May 2007 15:31:02 +0900
To: "Larry Masinter" <[email-masked]>, "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: RE: MPEG asks for MIME review for the MPEG21 file format
Cc: [email-masked], [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked]
Sender: [email-masked]

I fully agree with Larry's interpretation of RFC 3023 and his
comment on this proposal. "is XML" and "contains XML" are
two different things, and the "+xml" suffix is only for
the "is XML" case.

Regards,    Martin.

At 04:17 07/05/18, Larry Masinter wrote:
>I believe the +xml suffix should be reserved for media types whose content
>can be
>parsed without any preprocessing by a generic XML parser. A reply
>from David Singer indicated that the proposed MPEG 21file format is "binary
>and contains within it either XML text or BiM-encoded XML (like a ZIP
>archive
>with an XML document as the main document.)"
>
>In that case, the use of +xml would (IMO) be inappropriate.
>
>I thought this was clear form RFC 3023, but perhaps not.
>
>Larry

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

Date: Fri, 18 May 2007 07:54:32 +0200
To: "Chris Lilley" <[email-masked]>, "Larry Masinter" <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
From: "Anne van Kesteren" <[email-masked]>
Organization: Opera Software
Cc: "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, [email-masked], "'Christian Timmerer (ITEC)'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 18 May 2007 03:12:09 +0200, Chris Lilley <[email-masked]> wrote:
> The successor to RFC 3023 needs to indicate that binary XML which is  
> presented as a new encoding (in the xml sense) can use +xml, while other  
> binary forms cannot.

You wouldn't be able to still parse the retrieved resource in that case  
with a generic XML parser. Wasn't that the whole idea of +xml?

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Date: Fri, 18 May 2007 03:12:09 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: "Larry Masinter" <[email-masked]>
Cc: "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>, <[email-masked]>, "'Christian Timmerer (ITEC)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Sender: [email-masked]

On Thursday, May 17, 2007, 9:17:50 PM, Larry wrote:

LM> I believe the +xml suffix should be reserved for media types whose content
LM> can be
LM> parsed without any preprocessing by a generic XML parser. A reply
LM> from David Singer indicated that the proposed MPEG 21file format is "binary
LM> and contains within it either XML text or BiM-encoded XML (like a ZIP
LM> archive
LM> with an XML document as the main document.)"

LM> In that case, the use of +xml would (IMO) be inappropriate.

I agree.

LM> I thought this was clear form RFC 3023, but perhaps not.

The successor to RFC 3023 needs to indicate that binary XML which is presented as a new encoding (in the xml sense) can use +xml, while other binary forms cannot.

-- 
 Chris Lilley                    mailto:[email-masked]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: "Larry Masinter" <[email-masked]>
To: "'Dave Singer'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>
Cc: <[email-masked]>, "'Christian Timmerer \(ITEC\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: MPEG asks for MIME review for the MPEG21 file format
Date: Thu, 17 May 2007 12:17:50 -0700
Sender: [email-masked]

I believe the +xml suffix should be reserved for media types whose content
can be
parsed without any preprocessing by a generic XML parser. A reply
from David Singer indicated that the proposed MPEG 21file format is "binary
and contains within it either XML text or BiM-encoded XML (like a ZIP
archive
with an XML document as the main document.)"

In that case, the use of +xml would (IMO) be inappropriate.

I thought this was clear form RFC 3023, but perhaps not.

Larry