W3C home > Mailing lists > Public > www-tag@w3.org > February 2004

RE: 27 Jan 2004 Draft finding "Client handling of authoritative metadata" available

From: Williams, Stuart <skw@hp.com>
Date: Mon, 2 Feb 2004 16:44:23 -0000
Message-ID: <E864E95CB35C1C46B72FEA0626A2E808019004DC@0-mail-br1.hpl.hp.com>
To: "'Ian B. Jacobs'" <ij@w3.org>, www-tag@w3.org
Cc: duerst@w3.org

Ian,

> Hello,
> 
> I've made available the 27 Jan 2004 draft finding "Client 
> handling of authoritative metadata" [1]. I've edited it a 
> fair amount since the 10 Dec 2003 draft [2] based on comments 
> from Roy Fielding, Stuart Williams, and Martin DŁerst. I was 
> unable to produce a useful diff version.
> 
> Thank you,
> 
>  _ Ian
> 
> [1] http://www.w3.org/2001/tag/doc/mime-respect-20040127.html
> [2] http://www.w3.org/2001/tag/doc/mime-respect-20031210.html

Thanks for working on this, it's starting to look pretty good. I have a few
more comments and suggested improvements.

Stuart
--

Editorial:
----------
Section 2 Scenario's para beginning "Norm's "cool-style" is an XSLT style
sheet,..." 

Well... Norm's 'cool-style' is a relative URI reference to a resource with a
retrievable XSLT format representation. I guess I can live with the
colloquialism... but I prefer precision.

--

Section 3.1 2nd para:
"Once an agent knows how the prepresentation provider has identified the
representation data, the agent may process it in a number of ways." 
This needs rewriting - the 2nd clause seems causally dependent on knowledge
of a mechanism ("how the representation provider has..."). from our
discussion (phone) I think you are simply describing a sequence of steps -
we may have proposed a rewrite on the fly (this is just to put the comment
on the record).

Substantive:
------------

Section 2 Scenarios:

I think it might be better to replace the 2nd scenario with one that
illustrates the use of a 'type' attribute that overrides a media-type that
accompanies a representation. This seems to be one of the main points at
issue in the finding and we currently don't illustrate that with a scenario.

Section 3 "Why the representation..."
I think that this section might provide stronger justification for
authoritative source provided meta-data if it also presented other
possibilities with pros and cons: 

- representation source provided metadata is authoritative.
- representation source provided metadata is just a hint.
- receiver introspection (sniffing).
- referrer provided metadata authoritative (eg. overriding 'type'
attribute').
- referrer provided metatdata is just a hint.

--

3.2 Interpretation of Representation Metadata.

I think the firewall breach example in the 2nd bullet is pretty weak as
stated. 

*IF* the firewall is configured to keepout "text/*" as stated and the
firewall operates correctly, the only way that the agent can receive a
'text/plain' representation is from a source inside the firewall. ie. if the
firewall is operating correctly, the agent can't violate the firewall
configuration - at least as described in this 2nd bullet.

--
3.2 Interpretation of Representation Metadata.

I'd like a stronger example the pretty printing HTML example in the 2nd
bullet of the 2nd list. I don't have one to hand :-(

4. Inconsistency...

I think a subsection "4.x Ways of giving consent" might go a some way to
addressing Paul's comment on useability [2].

[1] http://www.w3.org/2001/tag/doc/mime-respect-20040127
[2] http://lists.w3.org/Archives/Public/www-tag/2004Jan/0068.html
Received on Monday, 2 February 2004 11:45:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:24 GMT