- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 07 Sep 2009 14:02:14 +0200
- To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
Marcin Hanclik wrote: > Hi Marcos, > >>> What you did in 192 characters, the access element does in 52. >>> >>> That is the point of the access element: to make these kind of >>> annoying declarations easy to write. > > I do not think that the conciseness is the main driver of this aspect of the config.xml. In a lot of cases, it is. It's the reason we don't have wrapper elements for icons, etc. > What matters seems to be semantics, specifically in the light of the security model and selectiveness of the intentions. Yes, this is of course, far more important. But making the expression of intent as easy to express as possible is very important (hence the conciseness, and taking out as much work as possible for developers) > The size of the expression could be lowered a bit, e.g. the IRI could be changed from; > http://www.w3.org/widgetfeatures/networkaccess/http > to > http://www.w3.org/wf10/na/http > and so on. No, we don't need another namespace. Even a short convoluted one. <access> in the widget namespace is already defined. I.e., <access> already means "http://www.w3.org/wf10/na/http", and it is much easier to remember and use. > From another angle: > We seem to agree to have implicit API versioning (in DAP) that result in multiplication of the size of the runtime code (note the performance impact), so having a few more characters in config.xml with clearly defined semantics seems not to be an issue, I think. We are entering a bikeshed discussion here. What we should be asking is if the expression of intent is clear in the declaration: 1. I wanna access resource X on the Web? what is the most brain-dead simple way I can do that? For me, personally, saying: <access uri="http://bla.com/some/resource"> is pretty simple, logical, and gets the job done for most use cases. Kind regards, Marcos
Received on Monday, 7 September 2009 12:02:57 UTC