John Gregg wrote:
Hi Marcos,
I'm doing the implementation for Chromium so I'm pretty familiar with
notifications. Although I'm fairly new to the process, I would be happy
to volunteer to help, since I would definitely like to see a new
notifications spec come together.
Great!
http://dev.w3.org/2006/webapi/WebSimpleDatabase/http://dev.w3.org/2006/webapi/DataCache/
FYI: you should probably copy-paste the link that nikunj sent in his email.
clicking on it takes you to http://dev.w3.org/2006/webapi/DataCache/.
dumi
Hi Marcos,
As a summary of the URI/IRI-related issues, we have currently the following as
far as I can tell:
1. URI/IRI normalization in PC [1], it is currently at I18N [2]
2. Widget URI issues related to internationalization [3]
The URI/IRI normalization in PC is mainly for attribute values
Hi Marcos,
I'm doing the implementation for Chromium so I'm pretty familiar with
notifications. Although I'm fairly new to the process, I would be happy to
volunteer to help, since I would definitely like to see a new notifications
spec come together.
-John
On Fri, Sep 4, 2009 at 9:35 AM,
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.
What matters seems to be
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.
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).
It is also not the case for the distinction between
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
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
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
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
11 matches
Mail list logo
