On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we just cross that
bridge when we get to it?) ?
Personally, I would recommend that we don't :) Version identifiers are
2009/3/17 Robin Berjon ro...@berjon.com:
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we just cross that
bridge when we get to it?) ?
Personally, I would recommend
On Tue, Mar 17, 2009 at 1:57 PM, Robin Berjon ro...@berjon.com wrote:
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we just cross that
bridge when we get to it?) ?
On Wed, Mar 18, 2009 at 9:35 AM, Andrew Welch andrew.j.we...@gmail.com wrote:
2009/3/17 Robin Berjon ro...@berjon.com:
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we
On Wed, Mar 18, 2009 at 9:49 AM, Andrew Welch andrew.j.we...@gmail.com wrote:
I agree. Changing the namespace is a bad idea. I didn't get the sense
that this is what Robin was suggesting, however.
I was referring to this part:
If at some point we make breaking changes, then we just change
On Wed, Mar 18, 2009 at 1:47 AM, Andrew Welch andrew.j.we...@gmail.com wrote:
Personally, I would recommend that we don't :) Version identifiers are
largely useless and experience shows that users use them wrong (e.g. a bunch
of SVG out there that's labelled as 1.1 is really 1.2, but people
I agree. Changing the namespace is a bad idea. I didn't get the sense
that this is what Robin was suggesting, however.
I was referring to this part:
If at some point we make breaking changes, then we just change the namespace.
--
Andrew Welch
http://andrewjwelch.com
Kernow:
Personally, I would recommend that we don't :) Version identifiers are
largely useless and experience shows that users use them wrong (e.g. a bunch
of SVG out there that's labelled as 1.1 is really 1.2, but people just
copy-paste the root element).
Agreed. This is the reason we did not
On 3/18/09 9:52 AM, Jonas Sicking wrote:
On Wed, Mar 18, 2009 at 1:47 AM, Andrew Welchandrew.j.we...@gmail.com wrote:
Personally, I would recommend that we don't :) Version identifiers are
largely useless and experience shows that users use them wrong (e.g. a bunch
of SVG out there that's
I think that is what we are doing. By not including a version
identifier, we remove the temptation to make backwards incompatible
changes protected by a version switch. Those are the type of changes
that are harmful since they require more complex authoring than much
of the web seems to use.
On Tue, 17 Mar 2009 21:56:52 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 17 Mar 2009 21:50:21 +0100, Anne van Kesteren ann...@opera.com
wrote:
* cross-origin request with preflight, actual request
If we want to follow redirects here at all we can only do it for
requests that
On Mar 18, 2009, at 09:35 , Andrew Welch wrote:
Are you sure changing the namespace is preferable to a version
attribute? Seems very drastic, and usually it's best to avoid doing
it as it makes all tools that process existing markup redundant.
I didn't say that changing the namespace should
Hi Robin,
The idea is that in version 1.1, 1.2, perhaps even 2.0, 3.0 we just add
elements and attributes, and when they are not understood they are simply
skipped.
Ok, but you do of course open yourself up to typos not revealing
themselves until quite far down the line (after parsing anyway)
It might be good to add an options element on the feature element to
allow options to be set for features using name-value pairs. For example:
feature name=http://clothing.com/api;
option name=fancy value=pants/
option name=color value=green/
/feature
Thoughts? comments?
Kind
On Wed, Mar 18, 2009 at 3:38 PM, Marcos Caceres marc...@opera.com wrote:
It might be good to add an options element on the feature element to
allow options to be set for features using name-value pairs. For example:
feature name=http://clothing.com/api;
option name=fancy value=pants/
Hi Andrew,
On Mar 18, 2009, at 13:34 , Andrew Welch wrote:
The idea is that in version 1.1, 1.2, perhaps even 2.0, 3.0 we just
add
elements and attributes, and when they are not understood they are
simply
skipped.
Ok, but you do of course open yourself up to typos not revealing
themselves
On Mar 18, 2009, at 15:38 , Marcos Caceres wrote:
It might be good to add an options element on the feature
element to allow options to be set for features using name-value
pairs. For example:
feature name=http://clothing.com/api;
option name=fancy value=pants/
option
Marcos Caceres marc...@opera.com writes:
It might be good to add an options element on the feature element
to allow options to be set for features using name-value pairs. For
example:
feature name=http://clothing.com/api;
option name=fancy value=pants/
option name=fancypants/option
Marcos
Regarding the requirement for validity checking zip relative paths in
widget signature [1] references, does the following change make sense
to you?:
Change last paragraph in section 5.1, Use of XML Signature in Widgets
to (only last sentence is changed, to two new sentences):
I've now split out the Server-sent Events and Storage APIs out of HTML5,
and I've removed the text for Web Sockets, which was split out earlier. By
popular demand I've also done some tweaks to the styling of these specs.
HTML5
http://dev.w3.org/html5/spec/
Server-Sent Events
Mark
One issue you raised was that we have MUSTS on algorithms in the
processing rules in section 7.1, but allow other algorithms in the
algorithm section with MAY.
After our previous email exchange, I suggest the following changes to
section 7.1 in Widget Signature [1] to address this
I wonder what the interaction between this and a manifest approach for
URI dereferencing would be. I could argue the case both ways, but
would be interested in your thoughts.
--
Thomas Roessler, W3C t...@w3.org
On Mar 18, 2009, at 20:53, Frederick Hirsch
frederick.hir...@nokia.com
I have updated the Widgets Signature editors draft, section 5.1 (use
of xml signature) with revised text for Reference constraints. This is
revised from what I proposed on list earlier as I tried to make the
two cases clear (and disallow other random external references):
I replaced:
I have updated the latest Widget Signature editors draft section 4
(locating and processing digital signatures) to no longer require the
first signature to be processed.
http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures
The language is now (numbering ok in draft):
Process the
On Wed, Mar 18, 2009 at 1:04 PM, Alexey Proskuryakov a...@webkit.org wrote:
Per the current XHR2 spec draft, upload progress events are not sent if the
cross-origin request didn't do preflight. What is the rationale behind this
requirement?
I used to think that this was necessary to prevent
Great stuff Ian! This is something I think a lot of people, me
included, is happy to see happening!
Of course I'd like to see even more stuff split out (*cough* window
*cough*), but I won't whine about it until I have an editor or draft
to propose :)
/ Jonas
On Wed, Mar 18, 2009 at 12:55 PM,
26 matches
Mail list logo
