W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

RE: [WARP] Last Call comments (1)

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Thu, 17 Sep 2009 16:57:10 +0200
To: Robin Berjon <robin@berjon.com>
CC: Marcos Caceres <marcosc@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2890C66322@OBEEX01.obe.access-company.com>
Hi Robin,

I understand the 80/20 principle.
It is about quality.
I am however not sure that publication of the spec as is will result in the companies listed below to adjust to the "correct" meaning.

>>BONDI has <network-access> which is different
It was done, because there was no <access> when BONDI discussed this.
And actually in BONDI no-one seems to be against the proposals of making the design more robust based on <feature>.
My proposal is not about syntax, but about semantics that is missing in WARP.


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Robin Berjon [mailto:robin@berjon.com]
Sent: Thursday, September 17, 2009 4:41 PM
To: Marcin Hanclik
Cc: Marcos Caceres; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote:
> As stated in my original email, one of the targets is that <access>
> is not an obstacle for DAP.

The design was based on:

  - not restricting DAP's ability to define a security policy
  - enabling boolean access to URIs
  - having pattern matching that covers most cases
  - making sure that web content that works outside of a widget can
work inside a widget

> It is currently undefined how the related access control will be
> done and we would probably want to avoid the situation that <access>
> is deprecated once DAP is ready with their model.

Quite the contrary. If all goes well DAP's security policy will be
available within a couple years, and after that we'll need another
year before it ships as presumably it'll have some degree of
complexity. That's all fine but the problem that we have today is that
people are shipping implementations with support for something a lot
like <access> but that are not compatible. Just off the top of my head
I know that Opera has their own stuff (which was the original
proposal), BONDI has <network-access> which is different, JIL has
something of their own with different default rules, and Microsoft has
a widget engine using <access> from the December 2008 PC draft.

What WARP does is that it provides the strictly minimal solution that
will make interoperability possible before DAP finishes its work,
while adhering to its fundamental design principles. If it gets
obsoleted, superseded, set on fire in public displays of wrath, or
trampled by a horde of arctic hippopotami on MDMA then great. The
primary goal is to gain 3 years of interoperability which we need to
have. A complementary goal is that since we want content created
conforming to WARP today to be valid forever is that the policies that
WARP enables should be expressible using whatever DAP comes up with,
so that <access> can be defined as simply a syntactical shortcut to DAP.

In other words it is future-proof *because* it is simple. It's
extensible (if we need to, which I don't think we should) because it's
XML (and because its processing model is intended for that).

Robin Berjon - http://berjon.com/


Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda


This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Thursday, 17 September 2009 14:58:17 UTC

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