W3C home > Mailing lists > Public > public-forms@w3.org > July 2007

Re: charter all set now?

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 4 Jul 2007 16:06:57 +0100
Message-ID: <640dd5060707040806sfcbcfc5j6284aae9d54887f1@mail.gmail.com>
To: "Chris Lilley" <chris@w3.org>
Cc: "T.V Raman" <raman@google.com>, boyerj@ca.ibm.com, public-forms@w3.org

Hello all,

No doubt everyone will think I'm saying this because we are authors of
formsPlayer, a plug-in for IE...but I'm not. :)

I'm not following either the logic behind this line of reasoning, or
what is motivating it. We are working on plug-ins for IE _and_
extensions for Firefox I can certainly say that there is little
technological difference; both are 'browser extensions' which are not
part of the core browser code.

But I guess you might want to point out that a Firefox extension
created by Mozilla (the XForms extension) has a different status to an
IE extension created by someone other than Microsoft (formsPlayer).
Other than that there is little more that you can say about browser
extensions.

Regards,

Mark

On 04/07/07, Chris Lilley <chris@w3.org> wrote:
>
> On Wednesday, July 4, 2007, 12:08:04 AM, T.V wrote:
>
> TVR> Note that in today's browsers, there is a significant difference
> TVR> between "extension" and "plugin". Specifically, XForms for
> TVR> Firefox is an extension, *not* a plugin
>
> Yes, thats true and should be noted. An extension is closer to native support than a plugin.
>
> TVR> Chris Lilley writes:
>
>  >> On Wednesday, June 27, 2007, 8:44:10 PM, John wrote:
>
>  >> JB> There is only one diff-marked section that jumped out as really
>  >> JB> different from what the Forms WG otherwise understands as its
>  >> JB> mission, as expressed in charter mission statement.
>  >> JB>
>  >> JB> The mission statement seems to more accurately reflect our
>  >> JB> understanding, which is that it is the Forms WG mission to
>  >> JB> *develop* specifications that cover forms on the Web.
>  >> JB>
>  >> JB> Yet the description of the dependency between the Forms WG and the
>  >> JB> HTML WG says:
>  >> JB>
>  >> JB> "The Forms WG will work with the HTML WG to ensure that XForms
>  >> JB> Transitional processors will accept the HTML Forms developed by
>  >> JB> the HTML Working Group."
>  >> JB>
>  >> JB> The last part 'developed by the HTML working group' is
>  >> JB> problematic because it is the mission of the Forms WG to develop
>  >> JB> forms on the web, accounting via the joint task force for the
>  >> JB> forms requirements foreseen by the HTML WG.
>  >> JB>
>  >> JB> Despite this one case, I would say that my experience so far with
>  >> JB> the HTML WG suggests that their own opinions about how forms for
>  >> JB> the web are to be developed stems mostly from the fact that they
>  >> JB> do not feel bound by any statements expressed in a charter other
>  >> JB> than their own, despite the fact that you originally wrote them
>  >> JB> together.  They have expressed this directly, so this means that
>  >> JB> any statements of clarification would need to appear in both
>  >> JB> charters, not just the forms charter.
>
>  >> The html charter says
>
>  >>   The HTML WG and the Forms Working Group will work together in this
>  >>   Task Force to ensure that the new HTML forms and the new XForms
>  >>   Transitional have architectural consistency and that document
>  >>   authors can transition between them
>
>  >> so it seems that the existing charter already covers this. I discussed
>  >> this with the comm team and they said that the existing language
>  >> appeared to cover it.
>
>  >> JB> For example, there is a lot of confusion about the meaning of
>  >> JB> 'architectural consistency' and when I point to the key examples
>  >> JB> you give in the Forms WG charter, such as the expectation of
>  >> JB> "conversion from tag soup to *equivalent* XHTML serialization" or
>  >> JB> "following design principles such as separation of presentation
>  >> JB> from content", the response I get is that these are expressed in
>  >> JB> the forms charter so they are not binding on the HTML WG.
>
>
>  >> JB> That sounds an awful lot like the HTML WG feels it is the HTML
>  >> JB> WG's mission to develop specifications that cover forms on the
>  >> JB> web, which of course undercuts the Forms WG mission and
>  >> JB> discourages motivation for Forms WG members to participate in any
>  >> JB> kind of joint task force (despite my best efforts to encourage otherwise).
>
>
>
>  >> JB> I think it would be fair to rephrase "but relatively little
>  >> JB> traction in the mainstream, browser sector" to something more
>  >> JB> accurate, such as "despite having only indirect support from
>  >> JB> features available in modern web browsers."
>
>  >> We agree with that and have added similar wording (explicit mention of
>  >> plugins).
>
>
>  >> --
>  >>  Chris Lilley                    mailto:chris@w3.org
>  >>  Interaction Domain Leader
>  >>  Co-Chair, W3C SVG Working Group
>  >>  W3C Graphics Activity Lead
>  >>  Co-Chair, W3C Hypertext CG
>
>
>
>
>
>
> --
>  Chris Lilley                    mailto:chris@w3.org
>  Interaction Domain Leader
>  Co-Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
>  Co-Chair, W3C Hypertext CG
>
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Wednesday, 4 July 2007 15:07:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:44 UTC