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/
