Re: Representation header final proposal

Both.

MIFFY^H^H^H XOP will use the attribute to determine the media type for 
packaging; the application can decide whether to use the attribute or 
the structured metadata to determine the content-type. Yes, the 
duplication isn't great, but I think it's the best trade-off.


On Jan 23, 2004, at 2:09 AM, Jacek Kopecky wrote:

>
> Hi,
>
> for the particular case of the media type of a representation I expect
> there to be an attribute like xmime:media-type (found in PASWA) useful
> elsewhere, not just in the Representation header. Other metadata can be
> handled similarly or in a generic way by using some kind of <Metadata>
> element in Representation.
>
> I think a simple <Metadata> structure might be added to the core
> Representation header, but then we would have to answer the question of
> whether the media type indication uses the Metadata element, the
> media-type attribute, or both.
>
> The problem with full HTTP caches is that they require some knowledge 
> of
> the request headers, too, and those are not the same kind of metadata 
> of
> the representation. Yves's proposal suggested a <context> element
> listing the request headers.
>
> I don't think the request headers belong to the core Representation
> header.
>
> Again, I have no problem with us producing the extensions necessary for
> the Representation header to serve as a full HTTP caching mechanism, as
> long as the actual Representation header remains simple.
>
> Best regards,
>
>                    Jacek Kopecky
>
>                    Systinet Corporation
>                    http://www.systinet.com/
>
>
>
>
> On Wed, 2004-01-21 at 18:20, David Orchard wrote:
>> The TAG has said that a representation includes metadata (such as
>> media-type) of a representation. [1].  If people disagree with this, I
>> suggest they can send in Last Call comments on the Web arch document, 
>> or
>> this will become canon.
>>
>> Cheers,
>> Dave
>>
>> [1] http://www.w3.org/TR/webarch/#msg-representation
>>
>>> -----Original Message-----
>>> From: xml-dist-app-request@w3.org
>>> [mailto:xml-dist-app-request@w3.org]On
>>> Behalf Of Mark Nottingham
>>> Sent: Wednesday, January 21, 2004 9:03 AM
>>> To: Yves Lafon
>>> Cc: Jacek Kopecky; XMLP Dist App
>>> Subject: Re: Representation header final proposal
>>>
>>>
>>>
>>> That makes sense, except that the majority of URI schemes that are
>>> dereferencable use a MIME or MIME-like metadata/data
>>> packaging; I'd put
>>> forth that from an infrastructure standpoint, there's no need to
>>> differentiate between these protocols.
>>>
>>> It's true that there are dereferencable URI schemes that return
>>> representations that aren't MIME-like, but my first guess
>>> would be that
>>> they'll all like file, with a semantic of "bag of bits." That
>>> fits into
>>> a MIME-like model (with no headers).
>>>
>>> If we really want to allow non-MIME-like, non-bag-of-bits
>>> representations, I could see making a "MIME-like protocols" 
>>> extension.
>>>
>>> Cheers,
>>>
>>> P.S. What hath the TAG to say about the model (vs. form) of a
>>> representation? Can we just settle on MIME-like and be done with it?
>>>
>>>
>>> On Jan 21, 2004, at 5:03 AM, Yves Lafon wrote:
>>>
>>>> Well, that was the point of my proposal, however, Jacek's
>>> point (as I
>>>> understood it) is more:
>>>> * do a very raw thing
>>>> * extend to add extra information related to different protocols
>>>>
>>>> If we add <h:header> in the "HTTP" namespace, with all the necessary
>>>> information to act as a local cache, then I am happy, as long as we
>>>> don't
>>>> defer it to another spec.
>>>>
>>>>> If you don't want to send or use such metadata, that's your choice.
>>>>> However, if this mechanism is to be a drop-in replacement
>>> for the URI
>>>>> dereference function, I'd expect it to provide equivalent
>>> information
>>>>> when I need it. Otherwise, I don't see much point in the effort of
>>>>> standardising this header.
>>>>
>>>> What are the metadata for file: uri? Having a per-protocol extension
>>>> seems to be a good approach (we can even have family of
>>> protocol, as
>>>> some
>>>> share the same metadata schemes).
>>>
>>>
>>