Re: Some comments on 27 June 2003 Web Arch WD

> We discussed this at the Feb ftf meeting in Irvine
> http://www.w3.org/2003/02/06-tag-summary#archdoc-cl
>
> Though there was no formal resolution from that discussion,
> but you raised a similar point at that time. I believe the
> end of the discussion was to define representation to
> be data + metadata. The metadata included both the metadata
> about the data and the metadata about the message. In particular,
> Roy said:
>
>    "RF: Representation defined this way so that it has the same meaning
>     in both PUT and POST situations. You don't create messages on a
>     server; you create representations."
>
> Roy also said:
>
>     "RF: We know that that it was a mistake in HTTP to not be able to
>     distinguish msg metadata from representation data. We would fix 
> that
> in the next protocol spec."
>
> I take this as a proposal to reopen the definition of representation
> as I understood the TAG had decided it at the ftf meeting.

I don't agree with that summary at all.  The representation consists
of representation data and representation metadata.  There are other
things in the message, including control data (a.k.a. message metadata,
such as HTTP's Server field or the request method, URI, etc.),
resource metadata (e.g., Alternates, Vary, etc.), and sometimes
meta-metadata (for message-integrity checks).  In short, the
representation consists those bits that would not change content
regardless of the transfer protocol used to exchange them.  A
message usually, but not always, contains an embedded representation,
and it is a far better design to clearly encapsulate that distinction
using self-descriptive syntax within the message, rather than mixing
representation metadata and control data in the same field name space.

I thought I was pretty clear that representation != message.
My reading of the above quotes supports that as well.  The first
one doesn't make any sense if a representation includes metadata
that isn't about the representation data.

....Roy

Received on Monday, 14 July 2003 17:36:37 UTC