W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2003

Re: Representation header

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Mon, 3 Nov 2003 14:29:41 -0800
Message-Id: <37A3955E-0E4D-11D8-802A-00039396E15A@bea.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
To: noah_mendelsohn@us.ibm.com

+1

I think what we might end up doing is specifying the Representation 
header as a shell with slots for metadata (whether attributes or 
element children), paying special attention to the syntactic issues, 
transforming back and forth between XML and MIME headers, etc., and 
then define the media type indicator as something that slots in.

This reminds me of two issues in this area:
* media type or content-type - when we define this media type 
attribute, is is really the media type or the content-type? I.e., is it 
just a bare type/subtype or can it have parameters like content types? 
If it's just a media type, what are the implications WRT transforming 
back and forth to MIME?

* content encoding - should we have a separate piece of metadata that 
talks about the encoding? In MIME, that's Content-Transfer-Encoding; in 
HTTP it's content-coding. If we don't do this, it bakes base64 in as 
the only option ever (because it's implicit), so it may be beneficial 
to specify something like

<x:Representation media-type="image/jpg" content-encoding="base64">
  ...
</x:Representation>

This would allow you to have Representation headers that weren't base64 
(i.e., you could have XML in there, or plaintext, or css, etc.). Note 
that this is separate from the issue of what encodings <mtom:Include/> 
supports.


On Nov 3, 2003, at 2:12 PM, noah_mendelsohn@us.ibm.com wrote:

>
> I have a vague intuition that some of the metadata we might want to 
> carry
> is specific to the "Representation" header, but others might be 
> applicable
> to a broader range of MTOM content.  For example, just because my 
> binary
> is an image/jpeg doesn't mean I should need to claim that it's a cached
> copy of some particular URI.  So, I'd claim we want to allow media type
> annontation on most any child element that's base64Binary.  Perhaps the
> same for some others such as content-encoding, content-language, etc.  
> On
> the other hand, I would think that the URI being cached is pertinent 
> only
> to the Representation header.  So:  would it be worth a bit of energy 
> to
> sort out which things apply only to Representation and which to a 
> broader
> range of MTOM content.
>
> BTW:  It's really too bad that XML doesn't have structured attributes, 
> as
> many of the MIME headers would seem to fit nicely as structured 
> attributes
> on the corresponding base64Binary representation of the content.
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
Received on Monday, 3 November 2003 17:29:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT