RE: [WARP] Last Call comments (1)
Hi Marcos, Re 99% fulfillment of the needs: As stated in my original email, one of the targets is that access is not an obstacle for DAP. 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. So we may fulfill 99% of the needs now, but 1% in a few months with the access element. That is why I proposed a more robust and extensible (hopefully future-proof) design of the functionality based on feature element. What's more, the conditional character of feature brings flexibility to the design of widgets/webapps and may be important from their usability point of view. I don't understand the above sentence, can you give me an example of what you mean? Here I refer to the absence of the @required attribute on access element and its presence on feature element. By flexibility I mean the fact that access to some web resource could be conditional (i.e. not-required). Let's say my widget wants to retrieve resources from 2 websites / domains. One website provides the core functionality of the widget, i.e. the resources from it are mandatory/required, instantiation of the widget without access to those resources makes no sense etc. The second website provides additional functionality, a kind of nice-to-have for my widget. So access to the resources from this website is optional (@required=false). Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Monday, September 07, 2009 3:37 PM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) Marcin Hanclik wrote: Hi Marcos, is pretty simple, logical, and gets the job done for most use cases. The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains). Access requests for those are not relevant, IMO. Those would be controlled by the policy of the UA. (e.g., policy may say all 'tel:' and 'mailto:' are allowed and handled by the appropriate scheme handler - the phone dialer or the mail app.) I don't see any use case for access uri=mailto:*...@gmail.com; or access uri=tel:+47*. That's overkill, IMO. access covers the common (+99%) use case of accessing stuff on the Web. Like I said, other scheme handlers can handle tel, mailto, etc. like is currently done by browsers. It is also not the case for the distinction between programmatic vs. declarative/URL (not sure how to name it :) ) access. Those aspects may be important from the DAP's security model perspective. Key word here is may: you are adding solutions before you have a problem. Just focus on solving the issue at hand. Most use cases currently entails a few assumptions implicitly, e.g. relation to installation-time or dynamic access to the resource etc. Let me make the assumptions explicit: Most use cases for Opera = the Opera gallery of Widgets and what our developer community need and want. They want access to, for instance, the flickr API, the Google APIs, Twitter, etc. and the ability to mash up stuff really quickly, painlessly, and easily. They (and I) want a super easy to use platform that kicks ass for developing and delivering client-side applications. My goal is to give that to them:) I'm sure your goals are the same. In the future, they might want access to features provided by dap. Hopefully, they won't have to request those through a feature element (i.e., the APIs will just be there for them to use without requesting them), but, in the unfortunate case that they do have to request them, I want to make sure it's as simple as possible. What's more, the conditional character of feature brings flexibility to the design of widgets/webapps and may be important from their usability point of view. I don't understand the above sentence, can you give me an example of what you mean? Kind regards, Marcos Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE 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.
RE: Normalization, was: RE: [Widget URI] Internationalization, widget IRI?
Hi Marcos, Thanks for your comments. It seems we are aligned. UAs will just have to deal with that internally I assume there could be an easy solution to the normalization: The normalization / mandating some equivalence-determining algorithm (from RFC3987) could go into PC. Then maybe I18N would not have to be bothered further. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Monday, September 07, 2009 4:33 PM To: Marcin Hanclik Cc: Robin Berjon; public-webapps WG Subject: Re: Normalization, was: RE: [Widget URI] Internationalization, widget IRI? Marcin Hanclik wrote: Hi Marcos, The spec just treats them as opaque strings. Yes. This is the reason for my email to I18N. Ok, so what you are saying is, given an XML document's encoding, any URI should be converted to a default encoding (say, UTF-8)? This is one of the proposed solutions. In the email to I18N I asked/suggested that moving everything to UTF8 could be studied, but I was not sure whether it is ok for the developers who could have non-UTF8 text editors at hand (assuming config.xml is developed some basic text editor). That's ok. Best practice for developers is to write XML in UTF-8. If a developer writes XML in some obscure encoding, then, it is to their determent. The same would happen on the Web, you can't stop that. And, if a new super format emerges that is better than UTF-8, developers should be able to use it (and UAs support it). The main motivation for default encoding is to move from octets to characters. Yep. Opaque strings with pct encoding bring unnecessary encoding that should actually vanish if the URI/IRI normalization would be mandated. This is why we treat them as opaque strings. I can make this explicit. Perfect. widget id=foo:mañana is a valid URI. This is BTW comment: it seems to be IRI, since ñ is non-ASCII. A crap. I meant valid IRI (if I say URI again, just pretend I meant IRI :)). Right. That is an implementation detail - my implementation might be super internally optimized to run UTF-16. But, as you always know what the bytes are from the XML file, there should be no problem for comparison: XML file(utf-8 or ISO--Y)-- UA (UTF-16)-- zip archive(CP437|UTF-8) Agreed. To sum up: The whole issue about IRI/URI normalization is about treatment of the IRI-valued attributes as a string of characters and not as a string of octets. Such normalization is currently not in PC and my understanding is that the normalizations mentioned in RFC3987 must be explicitly mandated in specs using it to make them effective. Ok, I was not aware that RFC3987 says we have to normalize IRIs to a canonical form. Grumble... guess I gotta read that spec again :( Like I said, the way we designed this was that IRIs were just opaque strings. The internal representation of that string is irrelevant, but the following metadata is maintained: 1. the string is treated as a IRI (hence, could be normalized, if need be). So a = new IRI(someString); 2. The encoding of the IRI recorded for transcoding (as needed). IRIs come in two flavors: encoded and normalized. Mandating one over the other to developers is a waste of time. UAs will just have to deal with that internally (I guess that's what RFC3987 is for). Character-set conversion is another issue. In [1] I wrote: So by inclusion of [XML], it seems that other encodings than UTF-8 are implicitly mandated, or? I am not sure whether this is the understanding in WebApps. Yes. This is certainly the understanding in Web Apps. A UA can support whatever encodings it wants. A UA is only required to support UTF-8 - every other encoding optional (though you would be pretty silly if you didn't support a few common encoding formats, but we leave those to the market). And it seems that this is to be pending for discussion in I18N [2]. Ok, now that I'm starting to understand all this a bit better, I might be able to contribute to [2]. Thanks again for helping me understand the problem. Kind regards, Marcos [2] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0065.html Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE 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.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, Sep 8, 2009 at 1:21 AM, Mark Bakerdist...@acm.org wrote: I don't understand. In what scenario would a script be comparing URIs produced by different implementations? implementations tend to be stupid and parse things by hand. if you don't believe this, all you have to do is look at the html5 discussion about c:\fakepath
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sep 8, 2009, at 00:21 , Mark Baker wrote:
On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjonro...@berjon.com wrote:
On May 23, 2009, at 19:21 , Mark Baker wrote:
Right. That's the same point Arve made. I don't see a problem with
it. Sure, a widget will be able to discover an implementation
detail
of its widget container - the base URI - but it's still up to the
container to permit or deny access to other resources from that
widget
when asked to dereference it, whether the widget discovered the URI
via a mechanism such as the one you describe, or even if it simply
guessed it.
Calling it an implementation detail doesn't make it one. Say I have
a script
in which I need to identify resources that I'm currently using from
within
the widget. Since I don't want to have to care how the designers
linked them
in, I'll use their absolute URIs to compare them. If implementation A
returns http://magic-widget-host.local/dahut.svg;, and
implementation B
file:///special-widget-mount/dahut.svg, and C gives me made-up:/
dahut.svg
we don't exactly have interoperability.
I don't understand. In what scenario would a script be comparing URIs
produced by different implementations?
Know which section you're in to highlight a given button:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
I won't say that it's necessarily the best-written code, but it's not
daft enough to be shrugged off and it's not particularly contrived.
It's easy to come up with a bunch of similar cases. If you get one
implementation with more market-share than the others, then they'll
have to copy its behaviour, and we'll then have to specify it.
--
Robin Berjon - http://berjon.com/
[widgets] Reminder: Comments on LCWD of Widgets APIs and Events spec due 15 Sept 2009
September 15 is the deadline for comments on the August 18 Last Call Working Draft of the APIs and Events spec: http://www.w3.org/TR/2009/WD-widgets-apis-20090818/ The comment tracking document for this LCWD is: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- apis-20090818/ -Regards, Art Barstow Begin forwarded message: From: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com Date: August 18, 2009 11:40:08 PM EDT To: public-webapps public-webapps@w3.org Subject: [widgets] Seeking comments on Last Call WD of Widgets: APIs and Events spec; deadline 15 Sept 2009 Archived-At: http://www.w3.org/mid/E780EE9A-C049-4A9F- b149-3c8d78df9...@nokia.com On August 18 a Last Call Working Draft of the Widgets: APIs and Events spec was published: http://www.w3.org/TR/2009/WD-widgets-apis-20090818/ Please send comments to public-webapps@w3.org by September 15 at the latest. As Marcos noted at [1], the title is misleading since the spec no longer defines Events. This error will be corrected before the document's next publication. -Regards, Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 0646.html
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, Sep 8, 2009 at 7:41 AM, Robin Berjonro...@berjon.com wrote:
On Sep 8, 2009, at 00:21 , Mark Baker wrote:
On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjonro...@berjon.com wrote:
On May 23, 2009, at 19:21 , Mark Baker wrote:
Right. That's the same point Arve made. I don't see a problem with
it. Sure, a widget will be able to discover an implementation detail
of its widget container - the base URI - but it's still up to the
container to permit or deny access to other resources from that widget
when asked to dereference it, whether the widget discovered the URI
via a mechanism such as the one you describe, or even if it simply
guessed it.
Calling it an implementation detail doesn't make it one. Say I have a
script
in which I need to identify resources that I'm currently using from
within
the widget. Since I don't want to have to care how the designers linked
them
in, I'll use their absolute URIs to compare them. If implementation A
returns http://magic-widget-host.local/dahut.svg;, and implementation B
file:///special-widget-mount/dahut.svg, and C gives me
made-up:/dahut.svg
we don't exactly have interoperability.
I don't understand. In what scenario would a script be comparing URIs
produced by different implementations?
Know which section you're in to highlight a given button:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
I won't say that it's necessarily the best-written code, but it's not daft
enough to be shrugged off and it's not particularly contrived. It's easy to
come up with a bunch of similar cases. If you get one implementation with
more market-share than the others, then they'll have to copy its behaviour,
and we'll then have to specify it.
The regex could just as easily have been written to exclude the
authority component of the URI. Do you have a better example?
Mark.
Re: Normalization, was: RE: [Widget URI] Internationalization, widget IRI?
Marcin Hanclik wrote: Hi Marcos, Thanks for your comments. It seems we are aligned. UAs will just have to deal with that internally I assume there could be an easy solution to the normalization: The normalization / mandating some equivalence-determining algorithm (from RFC3987) could go into PC. Then maybe I18N would not have to be bothered further. Ok, basically, to address this all we need to say is: If 'potential license href' is a valid IRI, then let 'widget license href' be the result of normalizing 'potential license href' in accordance with RFC3987. Same for author href. (Personally, I think this change is unnecessary because of the fact that implementers know these are IRIs already). Normalization would not apply to feature name or to the id. They are treated as XML Namespaces (i.e., opaque strings that conform as IRIs). In other words: id = http://www.example.org/r%E9sum%E9.xml; is not equal id = http://www.example.org/résumé; Try it out: test xmlns:y = http://www.example.org/r%E9sum%E9.xml; xmlns:test = http://www.example.org/résumé; y:aaa/ test:test/ /test Kind regards, Marcos
