Re: WebPlatform Browser Support Info

I've only had time to read it quickly, but it looks good! I actually 
have been thinking for the past few days to indeed split the proposal up 
in two parts: 1 for raw test-data, and 1 for the interpreted data. 
Especially since these 2 datatypes (although both about the same thing) 
have different boundaries and requirements. Given your proposal, I think 
that might actually be the way to go.

I'll give more in-depth comments later when I had the change to read 
more into the proposal.


Ronald



Tobie Langel schreef op 2013-10-24 00:14:
> Hi,
> 
> Pushed the first (unfinished) draft of a "counter" proposal[1]. I did
> this for two reasons:
> 
> 1) it's a lot harder to come up with a coherent proposal than to open
> 25 issues against someone else's,
> 2) I was under the impressions that I wasn't able to convey the
> overall organization I had in mind either through the mailing list or
> through the bug tracker.
> 
> The goal of this proposal isn't to replace Ronald's but to understand
> better the different perspectives so we can move towards consensus.
> 
> Right now it focuses mainly on:
> 
> - defining the UA part,
> - establishing a distinction between raw data (Test results) and
> interpreted data (Feature Support),
> - removing the url proxying.
> 
> In retrospect, I think that the main issues I have with Ronald's
> proposal have to do with the excessive (and unnecessary) use of
> identifiers and the use of test related terminology to describe what
> is essentially feature support info.
> 
> It is probable that I will end up with a two leveled proposal:
> 
> 1. UA string - test case - spec - test result (raw data)
> 2. UA object - Feature Support - Feature (interpreted data)
> 
> Where moving from one level to the other requires either code
> transformation (UA parsing) or interpretation.
> 
> Comments welcomed.
> 
> --tobie
> ---
> [1]: http://tobie.github.io/webplatform-browser-compat

Received on Wednesday, 23 October 2013 22:54:46 UTC