W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: UMP / CORS: Implementor Interest

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 11 May 2010 18:34:05 -0700
Message-ID: <AANLkTikwoLFT_TOXbh3JshcHxAyvVtSWZ7eodS5vmSue@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Dirk Pranke <dpranke@google.com>, Tyler Close <tyler.close@gmail.com>, Ojan Vafai <ojan@chromium.org>, Anne van Kesteren <annevk@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Arthur Barstow <Art.Barstow@nokia.com>
On Tue, May 11, 2010 at 3:16 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On May 11, 2010, at 1:57 PM, Jonas Sicking wrote:
>> On Tue, May 11, 2010 at 1:34 PM, Dirk Pranke <dpranke@google.com> wrote:
>>> On Tue, May 11, 2010 at 12:01 PM, Tyler Close <tyler.close@gmail.com>
>>> wrote:
>>>> On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai <ojan@chromium.org> wrote:
>>>>> What is the difference between an "authoring guide" and a
>>>>> "specification for
>>>>> web developers"?
>>>> The difference is whether or not the normative statements in UMP
>>>> actually are normative for a CORS implementation. This comes down to
>>>> whether or not a developer reading UMP can trust what it says, or must
>>>> he also read the CORS spec.
>>>>>  The key point of making this distinction is that
>>>>> implementors should be able to look solely at the combined spec.
>>>> No, the key point is to relieve developers of the burden of reading
>>>> and understanding CORS. The CORS spec takes on the burden of restating
>>>> UMP in its own algorithmic way so that an implementor can read only
>>>> CORS.
>>> If figuring out how to have two specs is too much hassle, you could
>>> probably get 90%+ of what people are looking for by putting all of the
>>> normative stuff in the CORS spec and writing an informational note
>>> describing UMP that only discusses the subset of CORS needed for UMP.
>> That is exactly what I propose. I'd also call the informational UMP
>> note developer documentation, and make it easier to read for
>> developers than what a spec could ever be. But that's less important
>> if people feel otherwise.
> The approach suggested by Dirk and Jonas seems sensible to me.

Yeah, me too.  That's what I meant by my comment above.  Two documents for two
audiences, each tailored to best suit its audience.

Received on Wednesday, 12 May 2010 01:35:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC