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

Hello Noah,

Firstly, I've read over the new version of the finding, which I like
alot. Thanks for taking the time to consider my comments and to produce
a new  draft. I have some follow up two of the comments below - but I
would not want resolution of either to further delay publication. 

Of the two follow-ups, if the suggested replacement text in the second
appeals, I would prefer it to the standing text. However, if it doesn't
appeal I will live with the status quo.

Wrt: to the various comments on the theme of authority,: They were made
because they reflected comments made to me by others (some
off-list)while the document was in my care and which I had been unable
to resolve to their satisfaction. I don't intend to push on that topic
any further.

Thanks again, best regards

Stuart
--
> -------
> 
> Commenting on:
> 
> > "Many URI schemes offer a flexible structure that can also be used
to 
> > carry additional information, called metadata, about the resource."
> 
> Stuart's comment:
> 
> > Do you have an example of such a scheme.
> > I can't think of any!!!
> 
> Sure, the http scheme for example.  I can encode into URIs in 
> that scheme creation dates, directory hierarchies, file 
> types, and all sorts of things.  It doesn't provide a 
> standard representation for any one of those, but that's not 
> the point:  it's a schema that "can be used" to carry such 
> information.  Indeed, the subject of the finding is when it 
> should be used in that way, and when consumers of URIs should 
> depend on it having been used that way.

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

> -------
> 
> Commenting on:
> 
> > 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 license 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. A correctly written browser 
> > would have shown the faulty
> > XML as text, or might conceivably have shown a warning about the
apparent
> > mismatch between the type inferred from the URI and the returned
Content-
> > Type. (Martin's browser is also ignoring TAG finding "Authoritative
Metadata"
> > [AUTHMETA], which mandates that the Content-Type HTTP header takes 
> > precedence even if type information had somehow been reliably
encoded 
> > in the URI.)
> 
> Stuart's comment:
> 
> > Comment [skw4]: It is in error because it construes that there is 
> > metadata intentionally placed in the URI when there is not.
> 
> Hmm.  You seem to be saying that we know conclusively that 
> there is no metadata in that URI, and I don't think that's 
> the case.  In fact, there may well have been metadata, even 
> in the .xml suffix in question.  The authority may have 
> decided to use .xml as a suffix for anything that was 
> originally intended as xml, and in this case has extended 
> that convention to some buggy XML that is in fact not well 
> formed.  I think the draft on the finding is correct as it 
> stands:  there may or may not be metadata in the URI, but the 
> point is we can't know whether it's there or how to interpret 
> it unless there are normative specifications or documentation 
> from the assignment authority.  I'm afraid I'm not convinced 
> on this one.

What I'm saying is that it is an error to construe the existence of
metadata in the URI where you have no license to do so. The bit of the
text that triggered the commment is:

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

which, in stating the error, implicitly acknowledges the presense of
metadata - an acknowlegment that I would rather avoid making. To be
constructive I'll suggest the following replacement text:

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

Received on Monday, 25 September 2006 11:31:28 UTC