Re: Revisiting Authoritative Metadata (was: The failure of Appendix C as a transition technique)

On 26/02/2013 05:14 , David Sheets wrote:
> On Mon, Feb 25, 2013 at 4:25 AM, Robin Berjon <robin@w3.org> wrote:
>> Right. But that information gets lost when you save the payload. People
>> don't go about saving HTTP messages to disk, they save the payload.
>
> I believe you mean end user agents save the payload. It is quite
> common for automated consumers to persist transactional metadata.

It is common for UAs to try to do that, too (typically by mapping to a 
file extension). But data often has a far more extensive life ccyle.

>> What one cares about transmitting most of the time is the payload, not the message.
>
> The message is the standard way to deliver the payload. If you just
> want to send the payload, use netcat. Or use HTTP without a
> Content-type header.

"If you want foo, use bar" is hardly a solution to the real world 
problem we're looking at.

Iff you use the protocol properly and iff you only speak to people who 
do so as well then you're right: everything is fine and dandy. But 
that's not an accurate description of reality.

>>> How is this an antipattern? It's very standard and very unambiguous.
>>
>> Something can be standard and unambiguous and yet still a bad idea.
>
> Between
>
> "Here's how you describe your content if you want."
>
> and
>
> "Sometimes people lie so don't bother telling the truth. Telling the
> truth is deprecated."
>
> It seems, to me, that the second is a bad idea.

Possibly, but then the dichotomy you describe above is a complete 
strawman and doesn't in the least relate to what I'm proposing. What I'm 
stating is:

• Splitting away information that is required for integrity serves no 
identified purpose and rather obviously introduces a weakness into the 
architecture; and

• Our documentation of the architecture is lying about the state of the 
world, let's make it tell the truth.

> That this heuristic is also useful when publishers lie to you is not a
> reason to silently disregard the sender's intent, "sniff", and present
> to an ignorant user. Fundamental interpretation errors and subsequent
> heuristic correction should be surfaced. That this is NOT the present
> behavior indicates, to me, an attitude of Browser Knows Best.

Well, as shocking as it may sound users seem to prefer tools that 
produce the results they want (accessing the content) over tools that 
condescend to them as "ignorant users".

> Yes, there are problems with the present system. Your suggestion of
> "everyone should just plan for ambiguous sniffing and we should
> deprecate declarative intent" appears to be removing publisher choice
> without any proposed replacement.

Give me a use case for sender intent. Then we can look at the merits of 
a technical solution that implements it.

http://w3cmemes.tumblr.com/post/34633601085/grumpy-old-maciej-has-a-question-about-your-spec

>> • The cost of error is born by the receiver, not the sender. In any such
>> system you are guaranteed to see receivers perform error correction, and
>> those will dominate over time (simply by virtue of being better for their
>> users).
>
> That's fine. Error correction is very important.
>
> It doesn't follow that declaring intent should be deemed an
> antipattern.

The antipattern isn't declaring intent. It's declaring any information 
required for the processing of a payload separately from that payload, 
*and* requiring it to be authoritative. Down that path lies breakage.

>>> What occasion would that be?
>>
>> The aforementioned revisiting of this issue.
>
> "On the occasion of my raising the issue, the issue should be settled." ?

Well, it's not the first time and I'm not the first person to point out 
that Authoritative Metadata is an anti-finding. Note that I'm not the 
one who brought up the notion of revisiting it, I simply took the 
opportunity to remind this community that we have a bug there.

> I add, here, that application/json does not guarantee dictionary
> ordering nor supply any higher-level namespace mechanism. How do you
> suggest JSON messages be transmitted in this New World?

As I've now said about twenty times in this thread, I'm not proposing 
that we remove content types, simply because we can't (if we could, I 
would). Further mentions of this strawman won't get a response.

We can't fix (most of) the data formats we have that don't include 
built-in typing. What we *can* fix is our advice that that's actually a 
feature, and rather recommend that future file formats do not repeat 
this mistake. It's too late to save JSON, at least until such a time as 
a v2 happens, if it ever does. If it *does* happen, you can bet that a 
builtin indicator will be at the top of my list.

> Yeah, but receipt from a remote publishing authority is the most
> salient indicator of intended interpretation. Instead of
> (unsuccessfully) convincing the world to adopt consistent and useful
> magic numbers for every content type, why not standardize this in a
> common protocol that carries any type of content?

Because we did that and failed?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 26 February 2013 11:27:52 UTC