RE: Representation header final proposal

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).
> >
> >
>

Received on Friday, 23 January 2004 05:10:07 UTC