Hi Nick,
On Feb 5, 2009, at 18:04 , Nick Allott wrote:
To clarify: BONDI work would have been introduced to W3C activity
earlier in the process, however, we have been fighting the internal
(and cross organisational) processes surrounding IPR regimes.
This is now fully clarified – and
On Feb 4, 2009, at 20:05 , Marcos Caceres wrote:
Yep. But like Charles said, it should be the other way around: Bondi
specs should be brought to the W3C for standardization once they are
ready. If the specs are done, implemented, and have an associated
test-suite, then standardization through
Apologies for entering thread late.
To clarify: BONDI work would have been introduced to W3C activity
earlier in the process, however, we have been fighting the internal (and
cross organisational) processes surrounding IPR regimes.
This is now fully clarified - and formal inputs will be
On Thu, Feb 5, 2009 at 3:03 PM, Robin Berjon ro...@berjon.com wrote:
On Feb 4, 2009, at 20:05 , Marcos Caceres wrote:
Yep. But like Charles said, it should be the other way around: Bondi
specs should be brought to the W3C for standardization once they are
ready. If the specs are done,
Hi Robin,
On Wed, Feb 4, 2009 at 11:29 AM, Robin Berjon ro...@berjon.com wrote:
On Feb 4, 2009, at 02:20 , Marcos Caceres wrote:
On Tue, Feb 3, 2009 at 11:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Is there a reason to require any formats? In very few places we do
this. For example the
The Web Apps WG should create yet another (short) widget spec, which would
be an Open Web profile spec that simply provides a checklist for two
interoperability levels for conformance. In both profiles, the user agent
would be required to implement all of the various Widgets spec. One
Hi Marcos,
On Feb 3, 2009, at 20:54 , Marcos Caceres wrote:
Ok, I've added SVG as a default start file type to the editor's draft
(I'll commit it to CVS later today). However, as this is a significant
addition, the Working Group will have to reach a resolution on this
(or raise objections
On Feb 4, 2009, at 00:22 , Jonas Sicking wrote:
Is there a reason to require any formats?
Interoperability?
In very few places we do
this. For example the HTML and CSS specs don't require support for
JPEG, GIF or PNG. Neither HTML or SVG require support for javascript.
Well, my point was
On Feb 4, 2009, at 15:13 , Marcos Caceres wrote:
To be clear, formats that need to be supported by a user agent will
not be mandated in the Widgets PC specification, which is only
concerned with packaging and configuration.
This solution addresses my concerns, thank you very much for your
Hi Jon,
On Feb 4, 2009, at 00:14 , Jon Ferraiolo wrote:
*IF* the WG decides to somehow promote SVG into a required format
for some features in the widgets spec, then either the spec or
implementations have to figure out how to deal with time-based
behaviors (e.g., animations) and
On Wed, Feb 4, 2009 at 6:48 PM, Jon Ferraiolo jfer...@us.ibm.com wrote:
Hi Charles,
Just because the OMTP is pay-to-play doesn't mean their efforts are wrong.
(Isn't W3C pay-to-play also?) My understanding is that all of the BONDI
technologies will be RF and published as open standards, and
On Wed, 04 Feb 2009 19:48:38 +0100, Jon Ferraiolo jfer...@us.ibm.com
wrote:
Hi Charles,
Just because the OMTP is pay-to-play doesn't mean their efforts are
wrong. (Isn't W3C pay-to-play also?) My understanding is that all of
the BONDI technologies will be RF and published as open
Hi, Jon-
Jon Ferraiolo wrote (on 2/4/09 11:48 AM):
Just because the OMTP is pay-to-play doesn't mean their efforts are
wrong. (Isn't W3C pay-to-play also?)
I don't know enough about the OMTP structure to judge whether they are
pay-to-play... but W3C is definitely not pay-to-play. W3C is
Hi Marcos,
*IF* the WG decides to somehow promote SVG into a required format for some
features in the widgets spec, then either the spec or implementations have
to figure out how to deal with time-based behaviors (e.g., animations) and
interactive behaviors (e.g., hyperlinks, onload, onclick,
Is there a reason to require any formats? In very few places we do
this. For example the HTML and CSS specs don't require support for
JPEG, GIF or PNG. Neither HTML or SVG require support for javascript.
Is there a reason for the widget spec to be different?
/ Jonas
On Tue, Feb 3, 2009 at
Hi Robin,
On Tue, Feb 3, 2009 at 5:54 PM, Robin Berjon ro...@berjon.com wrote:
Hi,
I'm sorry if this was discussed earlier, but I have no recollection of it
being brought up and I can't seem to dig up a reference to this issue from
the archives of the public lists of this WG or its previous
On Tue, Feb 3, 2009 at 11:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Is there a reason to require any formats? In very few places we do
this. For example the HTML and CSS specs don't require support for
JPEG, GIF or PNG. Neither HTML or SVG require support for javascript.
Is there a reason
On Feb 3, 2009, at 4:22 PM, Jonas Sicking wrote:
Is there a reason to require any formats? In very few places we do
this. For example the HTML and CSS specs don't require support for
JPEG, GIF or PNG. Neither HTML or SVG require support for javascript.
Is there a reason for the widget spec
Scott Shattuck wrote:
From the SVG Specification, Section G.7 Conforming SVG Viewers
...
Specific criteria that apply to only /Conforming Dynamic SVG Viewers/:
* *The viewer must have complete support for an ECMAScript binding
of the **SVG Document Object Model*
19 matches
Mail list logo
