Re: [widgets] Widgets URI scheme... it's baaaack!

[Mark Baker]

On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjon 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?

Mark.

Re: Normalization, was: RE: [Widget URI] Internationalization, widget IRI?

[Marcos Caceres]

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.


  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 P&C 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

Normalization, was: RE: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

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).
The main motivation for default encoding is to move from octets to characters.
Opaque strings with pct encoding bring unnecessary encoding that should 
actually vanish if the URI/IRI normalization would be mandated.

>>I can make this explicit.
Perfect.

>> is a valid URI.
This is BTW comment: it seems to be IRI, since "ñ" is non-ASCII.

>>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 P&C and my understanding is that the 
normalizations mentioned in RFC3987 must be explicitly mandated in specs using 
it to make them effective.
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."
And it seems that this is to be pending for discussion in I18N [2].

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0042.html
[2] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0065.html

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:01 PM
To: Marcin Hanclik
Cc: Robin Berjon; public-webapps WG
Subject: Re: [Widget URI] Internationalization, widget IRI?



Marcin Hanclik wrote:
> 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 P&C [1], it is currently at I18N [2]
> 2. Widget URI issues related to internationalization [3]
>
> The URI/IRI normalization in P&C is mainly for attribute values that are to 
> be IRIs. At present these are:
> a) @id in
> b) @href in
> c) @href in
> d) @name in

There is no normalization done on any of those values (by designed, and
modeled explicitly after the behavior of XML namespaces, which are also
not normalized). The spec just treats them as opaque strings.

Remember that the P&C UA does not do anything meaningful with any of the
metadata it collects (leaves that to other UAs). It merely validates
that data (The UA just checks if the value of the attribute is a "valid
IRI", that's it! And it certainly does not need to do any normalization
to check for validity).

For example, from the spec:

wid...@id:
"If the id attribute is used, then let id be the result of applying the
rule for getting a single attribute value to the id attribute. If id is
a valid IRI, then let widget id be the value of the id..."

Where "A valid IRI is one that matches the IRI token of the [RFC3987]
specification".

(i.e., read the @id value, if it is a valid IRI, save it.)

So:

 is not valid.

 is valid, and the value is "fooo:bar%20123".

 is a valid URI.

Also, lice...@href:
"If the href attribute is used, then let potential license href be the
result of applying the rule for getting a single attribute value to the
href attribute.
If potential license href is not a valid IRI or a valid path, then the
href attribute is in error and the user agent must ignore the attribute.
If potential license href is a valid IRI, then let widget license href
be the value of potential license href."

(i.e., read the @href value, if it is a valid IRI, save it.)

And so on... it's the same for the other attributes. We don't normalize
anything nor should they be normalized. They are just treated as opaque
strings.

The only place where it changes is if license href is a "valid path", in
which case a UA checks for the file internally in the package. I think
this is where you see issues arising...

> Your use cases seem to be related to the above, since you quote non-ASCII 
> character in the @src of.

Yes, zip relative paths, which are either CP437 or UTF-8 internally in
the widget package.

What is assumed is a layer of abstraction between the package and the
config document:

  cont...@src (xml, any *supported* encoding)
   <-->  UTF-

Re: [WARP] Last Call comments (1)

[Marcos Caceres]

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 mailto:*...@gmail.com";> or 
. That's overkill, IMO.


 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  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

RE: [WARP] Last Call comments (1)

[Marcin Hanclik]

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 programmatic vs. 
declarative/URL (not sure how to name it :) ) access.
Those aspects may be important from the DAP's security model perspective.

"Most use cases" currently entails a few assumptions implicitly, e.g. relation 
to installation-time or dynamic access to the resource etc.

What's more, the conditional character of  brings flexibility to the 
design of widgets/webapps and may be important from their usability point of 
view.

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



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: [Widget URI] Internationalization, widget IRI?

[Marcos Caceres]

Marcin Hanclik wrote:

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 P&C [1], it is currently at I18N [2]
2. Widget URI issues related to internationalization [3]

The URI/IRI normalization in P&C is mainly for attribute values that are to be 
IRIs. At present these are:
a) @id in
b) @href in
c) @href in
d) @name in


There is no normalization done on any of those values (by designed, and 
modeled explicitly after the behavior of XML namespaces, which are also 
not normalized). The spec just treats them as opaque strings.


Remember that the P&C UA does not do anything meaningful with any of the 
metadata it collects (leaves that to other UAs). It merely validates 
that data (The UA just checks if the value of the attribute is a "valid 
IRI", that's it! And it certainly does not need to do any normalization 
to check for validity).


For example, from the spec:

wid...@id:
"If the id attribute is used, then let id be the result of applying the 
rule for getting a single attribute value to the id attribute. If id is 
a valid IRI, then let widget id be the value of the id..."


Where "A valid IRI is one that matches the IRI token of the [RFC3987] 
specification".


(i.e., read the @id value, if it is a valid IRI, save it.)

So:

 is not valid.

 is valid, and the value is "fooo:bar%20123".

 is a valid URI.

Also, lice...@href:
"If the href attribute is used, then let potential license href be the 
result of applying the rule for getting a single attribute value to the 
href attribute.
If potential license href is not a valid IRI or a valid path, then the 
href attribute is in error and the user agent must ignore the attribute.
If potential license href is a valid IRI, then let widget license href 
be the value of potential license href."


(i.e., read the @href value, if it is a valid IRI, save it.)

And so on... it's the same for the other attributes. We don't normalize 
anything nor should they be normalized. They are just treated as opaque 
strings.


The only place where it changes is if license href is a "valid path", in 
which case a UA checks for the file internally in the package. I think 
this is where you see issues arising...



Your use cases seem to be related to the above, since you quote non-ASCII character 
in the @src of.


Yes, zip relative paths, which are either CP437 or UTF-8 internally in 
the widget package.


What is assumed is a layer of abstraction between the package and the 
config document:


 cont...@src (xml, any *supported* encoding)
  <-->  UTF-8 (mapping) <--> CP437 (zip archive)


They are exactly the same with regard to the above issues 1. and 2.
They differ on the CP437/UTF8 level.


Yes, but you know your input (the encoding of the XML document). If you 
know your input, then you can easily convert it to whatever your want ( 
CP437, UTF8, or whatever) so long as you support it.


The spec says:
"If doc is encoded in a format that is unsupported by the user agent, 
then the user agent must terminate this algorithm and treat this widget 
package as an invalid Zip archive."


Supported in this context means that the UA can convert from one 
encoding to another (e.g., BIG-5 to UTF-8).



The widgets URI is on the character level and my point was about naming it URI 
(octet-level, whereas IRI operates clearly on character level).


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)?



My comments to the details:

P&C addresses the transcoding from CP437 to UTF8 [4] ( however, only as SHOULD, 
so maybe it should be also SHALL? This was not raised yet and it is probably late 
now):
" For the sake of comparison and matching, it is recommended that a user agent treat 
all Zip-relative paths as [UTF-8]."


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)

Also, it's not too late change this if this is causing real issues in 
implementations (that is the point of CR- to gain implementation 
experience and fix bugs before proceeding to PR).



The "problematic" character in your case is 'ñ', U+00F1.
In CP437 it is has the value 0xA4, in ISO-8859-1 it is 0xF1.


Yes.


In UTF8 this character is encoded as the sequence of the following octets: 0xC3 
0xB1.


Yes.


The assumption of P&C seems to be that everything gets converted to UTF8.
The only issue is that this is an assumption.


I can make this explicit.

In the "rule for finding a file within a widget package", step 2:

2.  If path is not encoded in UTF-8, convert path to UTF-8.


My case of IRI and your cases with file name are similar with regard to this 
assumption.


Right.


Specifically in case of IRI w

Re: [WARP] Last Call comments (1)

[Marcos Caceres]

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. 
 in the widget namespace is already defined. I.e.,  
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:

http://bla.com/some/resource";>

is pretty simple, logical, and gets the job done for most use cases.

Kind regards,
Marcos

RE: [WARP] Last Call comments (1)

[Marcin Hanclik]

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 semantics, specifically in the light of the security 
model and selectiveness of the intentions.

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.

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.

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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of 
Marcos Caceres
Sent: Friday, September 04, 2009 5:04 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

Hi Marcin,
I tried to respond to this email, but in all honesty, I can't follow
your line of argumentation. Maybe you can list your main points as a
list (sorry, I'm a bit simple)...

From what I got, I agree that WARP is over reaching: It does not
address the requirements it lists from the Widgets 1.0: Requirements
document. Otherwise, I'll just leave it to Robin to respond.

I've made some notes on the proposed changes.

On Thu, Aug 27, 2009 at 8:06 PM, Marcin
Hanclik wrote:

> PROPOSED CHANGES
>
> Given the semantic similarities (or equivalence) between:
>
> http://example.org"; subdomains="true"/>
>
> and e.g.:
>
> http://www.w3.org/widgetfeatures/networkaccess/http"; 
> required="false">
>http://example.org"/>
> 


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 propose the following:
>
> 1. Change the name of the specification to "Widgets 1.0: Network Access 
> Feature" and focus on per-URI-scheme definition of the syntax dependencies 
> and functionality.
>
> Examples:
> a)
> The following feature could replace the generic network access (proposed in 
> the LCWD as "*" for @uri attribute):
>
> http://www.w3.org/widgetfeatures/networkaccess"; 
> required="true" />
>
> b)
> The following features could define the http and https access
>
> http://www.w3.org/widgetfeatures/networkaccess/http"; 
> required="false">
>http://example.org"/>
>
> 
>
> http://www.w3.org/widgetfeatures/networkaccess/https"; 
> required="true">
>https://example.org"/>
>
>
>
> 
>
> c)
> The following feature could define access to SMS feature:
>
> http://www.w3.org/widgetfeatures/networkaccess/sms"; 
> required="true">
> 
>
> http://www.w3.org/widgetfeatures/networkaccess/sms"; 
> required="true">
> 
>
> 2. Rewrite parts of the specification - specifically section 3, while keeping 
> its majority as is - to adhere to the syntax of the  and  
> elements as outlined above.
>
> 3. Refrain from specifying the default policy; remove the word security from 
> the specification (since this is to be handled in DAP).
>
> 4. Focus in the specification text only on declarative aspects of the 
> intention of the author of the widget, leaving e.g. prompting aspects for 
> DAP. I.e. assuming that the network access is conditional, what are the 
> implications for the widget's code and author in case the network access is 
> not present or its presence is dynamic? (e.g. provide a definition of the 
> event mechanism).
>
> 5. In order to be able to define the IRI for network access feature, another 
> document should probably be prepared that would also define the namespace for 
> the further feature definitions (e.g. http://www.w3.org/widgetfeatures/).
>
> 6. Focus in the specification only on http and https. "subdomains" attribute 
> / value of the parameter is valid mainly for this protocol family (also 
> including e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is 
> no RFC for some) have their own specificities, e.g. country calling/dialing 
> codes, shortcodes.
>
> Thanks.
>
> Kind regards,
> Marcin
>
> [1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/
> [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html
> [3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0294.html
> [4] http://www.w3.org/TR/widgets
> [5] http://www.w3.org/TR/widgets/#the-feature-element
> [6] http://www.w3.org/TR/widgets/#the-widget-family-of-specifications
> [7] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#introduction
> [8] http://www.w3.org/TR/2009/WD-widgets-a

Re: [WebSimpleDatabase] New spec, editor's draft available

[Dumitru Daniliuc]

>
> http://dev.w3.org/2006/webapi/WebSimpleDatabase/
>

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

RE: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

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 P&C [1], it is currently at I18N [2]
2. Widget URI issues related to internationalization [3]

The URI/IRI normalization in P&C is mainly for attribute values that are to be 
IRIs. At present these are:
a) @id in 
b) @href in 
c) @href in 
d) @name in 

Your use cases seem to be related to the above, since you quote non-ASCII 
character in the @src of .
They are exactly the same with regard to the above issues 1. and 2.
They differ on the CP437/UTF8 level.

The widgets URI is on the character level and my point was about naming it URI 
(octet-level, whereas IRI operates clearly on character level).

My comments to the details:

P&C addresses the transcoding from CP437 to UTF8 [4] ( however, only as SHOULD, 
so maybe it should be also SHALL? This was not raised yet and it is probably 
late now):
" For the sake of comparison and matching, it is recommended that a user agent 
treat all Zip-relative paths as [UTF-8]."

The "problematic" character in your case is 'ñ', U+00F1.
In CP437 it is has the value 0xA4, in ISO-8859-1 it is 0xF1.
In UTF8 this character is encoded as the sequence of the following octets: 0xC3 
0xB1.

The assumption of P&C seems to be that everything gets converted to UTF8.
The only issue is that this is an assumption.
My case of IRI and your cases with file name are similar with regard to this 
assumption.

Specifically in case of IRI we have the issue of pct encoding, in your cases we 
have "just" character-set transcoding.

I hope it is clearer now.

Thanks,
Marcin


[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0644.html
[2] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0065.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0339.html
[4] http://www.w3.org/TR/widgets/#zip-relative-paths
[5] http://www.w3.org/TR/widgets/#the-content-element

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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of 
Marcos Caceres
Sent: Friday, September 04, 2009 11:11 AM
To: Marcin Hanclik
Cc: Robin Berjon; public-webapps WG
Subject: Re: [Widget URI] Internationalization, widget IRI?

On Thu, Sep 3, 2009 at 1:32 PM, Marcin
Hanclik wrote:
> Hi Robin,
>
> Thanks for your comments.
>
> I believe the terminology could be clarified once the IRI/URI issue from P&C 
> gets solved in I18N, hopefully together with HREF and all related stuff.
>
> +1 for simplification.
>

I'm still not understanding the problem in the P&C spec.

Let me try to walk through a simple widget. Marcin, pretend I'm 9
years old and explain the problem to me in the most simplest of terms
possible (i.e., don't cite me URI/IRI spec stuff because all that
stuff makes no sense, just talk to me about bytes... I'm one those
smarty 9 year-olds, who knows about bytes, but as a consequence gets
pushed around by bullies...:)).

USE CASE 1
1. I have a widget called foo.wgt. The widget contains 2 files:
mañana.html and config.xml.
2. The file names of both files are encoded in the zip archive as
UTF-8 (explicitly marked as such by the presence of a flag).
3. In the config doc, which is encoded in iso-8859-1, it says:
   
4. The UA reads the value of src attribute and converts it to UTF-8.
5. The UA matches the string that represents the value of src to the
"mañana.html" file entry.
6. done?


USE CASE 2
1. I have a widget called foo.wgt. The widget contains 2 files:
mañana.html and config.xml.
2. The file names of both files are encoded in the zip archive as
CP-437 (explicitly marked as such).
2.1 The UA maps all the files names in the zip archive to UTF-8 equivalents.
3. In the config doc, which is encoded in iso-8859-1, it says:
   
4. The UA reads the value of the src attribute and converts it to UTF-8.
5. The UA matches the string that represents the value of src to the
"mañana.html" file entry.
6. done?


--
Marcos Caceres
http://datadriven.com.au



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: Web Notifications, do we need a new spec?

[John Gregg]

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, Marcos Caceres  wrote:

>
>
> Ian Fette (イアンフェッティ) wrote:
>
>> We are in the middle of implementing in WebKit and in Chromium, so yes
>> we are still interested in pursuing. John Gregg (johnnyg@) has been
>> leading the effort from our end.
>>
>> Beyond an implementation that people can experiment with, what sort of
>> resources are you looking for?
>>
>
> Basically, a spec editor. We need to formally gather the requirements and
> just start writing. I was personally hoping to do this, but I don't have the
> cycles or experience in this area (which is why I'm asking you guys if you
> can help me out).
>
> Kind regards,
> Marcos
>

Re: Web Notifications, do we need a new spec?

[Marcos Caceres]

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! Basically, we just need a plain-text brain-dump from you about
how your implementation works and what the APIs. That should be
sufficient as a starting point to get the ball rolling. As I've got some
experience writing W3C specs, I'm happy to help co-edit.

Before starting on an actual spec, the parts we need are:

Requirements:
   a simple list of what the requirements are.
   (e.g., there must be a means to request the user's attention.)

APIs: some IDL (or pseudo code) and a brief description of each of the
attribute or method.

A description of how you envision notifications play with HTML5's
browsing contexts/origin.

You might also look at what we originally had in the widget spec (search
for "The showNotification()  Method" and "The getAttention() Method"):

http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-api/Overview.src.html?rev=1.87&content-type=text/html;%20charset=iso-8859-1

showNotification() was based on some old HTML5 text, which was removed
about a year ago. Anyway, please let us know if you need anything else,
and we look forward your input! :D

Kind regards,
Marcos