RE: Revised draft finding: Client handling of authoritative metad ata

Ian,

A few more comments below.

Stuart
--

Editorial:
----------

1 Summary of Key Points: Para 3: "Section 3 discusses the motivation of a
Web Architecture where origin metadata is authorative." '...a Web
Architecture..." seems a strange expression. Suggested rewording: "Section 3
discusses the design choice in Web Architecture that metadata supplied by
the originator of a message is authorative."

3 Why metadata from...:
2nd list: item 2: Reword "URI schemes may specify how names are
allocated..." to "URI schemes may specify how identifiers are allocated..."

2nd list: item 3: Reword "The resource provider communicates the state of
the resource with bits, the resource providers server exchanges these bits
with clients." to "The resource provider comminicates the state of a
resource by exchanging of representations with clients." Dropping to 'bits'
seems a little too coloquial.

3rd para: 1st sentence: Reword "Interpretation of bits on the internet is
governed by protocol specifications." as "Interpretation of representations
on the [internet|web] is governed by protocol and/or format specifications."

5 Hints in specifications: last para: Is SMIL 2.0 consistent or inconsistent
with the finding. The words say consistent, but the explaination seems
inconsistent to me.



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

3 Why metadata from...:
2nd list: item 2: "...the party that creates a URI has the right to
establish the authorative meaning of the resource." I find the phrase
"...authorative meaning of the resource." problematic. I'd be ok if it spoke
about the assignment of authorative metadata - I'd be wary of speaking of
meaning - and whether or not it is in the 'eye' of the beholder, and
multiple levels of meaning. If what we're talking about is originator
assigned metadata, then that is what we should say... and not dress it up as
"authorative meaning of a resource."

2nd list: item 4: "The user's clients interpret bits according to
specifications." Firstly, s/bits/representations. Secondly, need to be more
particular about which specifications are applicable.

3rd para: last sentence: "The IANA registry maps media types to data format
specifications." to "The IANA registry maps media types to their associated
format specifications via intermediate media type registrations."

3.1 Multiple interpretations...
I'd rephrase this entire section in terms of a single authorative media
type. 

3.2 Metadata and efficiency:
I think it would be good to indicate that the representation data must be
consistent with the authorative media type. If there is an inconsistency
then that is an error.

4 Why agent behaviour...

1st para bulleted list: Both examples are bascially the same - client
'sniffs' the data and ignores media-type. You also describe this as
misrepresenting the user, whereas to me it seems more a case of
misrepresenting the server. 

4.2 Client handling of inconsistencies.

2nd para: bulleted list: add (wtoe) "Use the hint to express a preference,
eg. via HTTP Accept headers."

last para: Tries hard to manoeuvre around the question of separating the
expression of what something is from the way a particular recipient
processes it. I wish I had an alternate to suggest... the important theme
for me is separating the expression of what something is from the
constraints on how it is processed by the recipient.


> -----Original Message-----
> From: Williams, Stuart [mailto:skw@hp.com] 
> Sent: 15 December 2003 19:54
> To: 'Ian B. Jacobs'; www-tag@w3.org
> Cc: ph@w3.org; duerst@w3.org
> Subject: RE: Revised draft finding: Client handling of 
> authoritative metad ata
> 
> 
> 
> Ian, 
> 
> I've started to re-review the mime-respect finding and have 
> tripped up on a couple of things [I haven't made it all the 
> way through yet]:
> 
> 1: Message sender or Origin Server?
> -----------------------------------
> "The Web architectecture uses representation metadata to 
> indicate the senders intentions..."
> 
> and
> 
> "...we review the architectural design choice that metadata 
> provided by an origin server be authoratative."
> 
> Whilst the latter does not contradict the first it does lead 
> to a level of confusion as to whether the intended principle 
> is that the representation metadata supplied by the sender of 
> a representation is authoritative - eg. in the case of 
> metadata accompanying an HTTP PUT request, or say, the MIME 
> packaging of an email message.
> 
> The key point summary seems to make it clear... and then the 
> 3rd para of the Introduction states "Section 3 discusses the 
> motivation for a Web architecture where origin metadata is 
> authoritative." This introduces a term 'origin metadata' 
> without being clear whether it relates to the sender of a 
> representation or an origin server.
> 
> 2: Section 3
> ------------
> The title of section 3 introduces the term "resource 
> provider" and then seems to confuse resource and 
> representation in the 1st paragraph.
> 
> Also, "...in general, that the provider of a resource assigns 
> the authoritative interpretation of representations of a 
> resource." I think I picked on this language before when it 
> propagated into a draft of the arch document. Suggest 
> replacing with: "...in general, that the provider of a 
> representation is the authoritative source of representation 
> metadata including media-type which is used to determine how 
> to interpret the representation." I'm also a little nervous 
> of what this means in transcoding situations.
> 
> More later,
> 
> Cheers,
> 
> Stuart
> --
> 
> 
> 
> 
> > -----Original Message-----
> > From: Ian B. Jacobs [mailto:ij@w3.org]
> > Sent: 10 December 2003 23:19
> > To: www-tag@w3.org
> > Cc: ph@w3.org; duerst@w3.org
> > Subject: Revised draft finding: Client handling of 
> > authoritative metadata
> > 
> > 
> > Hello,
> > 
> > I've revised the finding "Client handling of authoritative
> > metadata" based on input from Roy Fielding, Philipp Hoschka, 
> > Martin Duerst, Chris Lilley, and in light of the language 
> > used in the Last Call Arch Doc. I reused much of the language 
> > Roy provided for the first three sections, then extrapolated 
> > from there.
> > 
> >  - Ian
> > 
> > 10 Dec 2003 Draft finding
> > http://www.w3.org/2001/tag/doc/mime-respect-> 20031210.html
> > 
> > Diff:
> > http://www.w3.org/2001/tag/doc/mime-respect-20031210-diff.html
> > -- 
> > Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
> > Tel:                     +1 718 260-9447
> > 
>

Received on Friday, 19 December 2003 12:39:02 UTC