RE: Proposed disposition of Stuart Williams' comments on Metadata in URI 31

Hello Noah,

<proposed>
> Martin's browser is in error, because its inference that the 
> URI suffix provides file type metadata is not provided for by 
> normative Web specifications or (we may assume) in 
> documentation from the assignment authority.
> </proposed>

Thanks... that looks fine. 

Stuart
--

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: 30 September 2006 01:05
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org
> Subject: RE: Proposed disposition of Stuart Williams' 
> comments on Metadata in URI 31
> 
> Stuart Williams writes:
> 
> > Ok... I understand the point, but I still think that citing http as 
> > such a scheme (as you do in your response above - not the document) 
> > sort of over states things. In asking for examples, I was looking
for 
> > examples where explicit provision was made for carrying additional 
> > information, with the explicit intent that the information be 
> > recoverable my inspection of the URI.
> 
> I understood that to be your intent.
> 
> > Maybe I read to much into the "CAN", but that is what I read it as 
> > suggesting.
> > 
> > I guess that we can agree to differ on this one.
> 
> With some reluctance, I think so.  More specifically, I'm at 
> the point where I'd prefer to rely on other TAG members to 
> give guidance on which of these things are worth another 
> round.  My vote would be to leave this one as is, with 
> apologies for having taken advantage of your flexibility in 
> agreeing to something that you don't completely like.
> 
> Stuart suggests:
> 
> > "Martin's browser is in error because it treats a portion of the URI

> > as metadata in a way that is not covered by normative specifications

> > and has not been documented by the assignment authority."
> 
> I can live with that, but would prefer the following change:
> 
> <originalFromSept16Draft>
> In this example, there is no normative specification that 
> provides for determination of a media-type from URI suffixes, 
> and the assignment authority has provided no documentation to 
> support an inference of media-type from the URI. Martin's 
> browser is in error, because it relies on URI metadata that 
> is not covered by normative specifications and has not been 
> documented by the assignment authority. 
> </originalFromSept16Draft>
> 
<proposed>
> Martin's browser is in error, because its inference that the 
> URI suffix provides file type metadata is not provided for by 
> normative Web specifications or (we may assume) in 
> documentation from the assignment authority.
> </proposed>
> 
> I'd like to think that this retains the essence of your 
> improvement, but I like the way it reads a bit better.  It 
> eliminates the whole first sentence of the paragraph, and I 
> think it also is a bit tighter than the sentence you offered 
> (though I can live with that too). 
> 
> I'm taking the liberty of including my proposed revision in 
> the draft that's about to ship, but feel free to push back if 
> you feel yours is better.  We'll also have to see whether 
> other TAG members concur with the change.  I hope this 
> addresses what I take to be your main concern, which is the 
> suggestion that there might have been some metadata there to ignore.
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
>

Received on Monday, 2 October 2006 07:27:10 UTC