OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Browser innovation efforts -- where's W3C in this picture?

[ Lists Home | Date Index | Thread Index ]
  • To: "Bjoern Hoehrmann" <derhoermi@gmx.net>, "Michael Champion" <mc@xegesis.org>
  • Subject: RE: [xml-dev] Browser innovation efforts -- where's W3C in this picture?
  • From: "Micah Dubinko" <MDubinko@verity.com>
  • Date: Tue, 6 Jul 2004 23:43:17 -0700
  • Cc: "XML Developers List" <xml-dev@lists.xml.org>
  • Thread-index: AcRjycB0tZpL57KrRjGpLCPrV55B+QAGg4/w
  • Thread-topic: [xml-dev] Browser innovation efforts -- where's W3C in this picture?

[Disclaimer: I'm with a different company now, and in no way connected to the W3C anymore. I speak only for myself.]

>Bjoern Hoehrmann wrote:
>
>I have however good faith that they would sort this out. To me it seems
>that they do not think that XForms is clearly a superior solution for
>forms on web sites. Is it?

The XForms folks and the WHAT folks are too brilliant not to sort it out, eventually, but the current communications loop (or lack of one, rather) isn't helping.

Lots of people seem to indicate that a smaller subset of XForms would be useful. XForms Basic is still in CR [Since November 2002]. WHAT would be a great forum to help sort out that mess, and the result a single stronger solution, rather than two marginally competing ones.

Why isn't this happening?

>And if it is, can we tell content providers anything else than to wait
>three to six years to use XForms on their web site? And if not, what is
>exactly wrong with creating something that can be used in the meantime?

Web Forms 2.0 is trying to cover three kinds of territory:
 1) Stuff that works in IE today (autocomplete, but I'd throw in XMLHTTP, contenteditable, spell-check I think)
 2) Stuff acceptable if ignored (required, etc., requires a server check anyway)
 3) Complicated stuff (repeats, everything else)

Everything in 1) should be specified as modules that could be used in either "classic" forms or XForms.

Everything in 2) should be specified as a subset of XForms (probably XForms 1.1, which has requirements to reduce namespace friction). Depending on how deep you need to cut, even XPath isn't necessary. (It isn't substantively used in the 'lazy author' syntax, for example). This is not a "backwards-compatibility" problem, given today's browser cores.

Other than repeats, which XForms handles adequately, do we need anything else in 3) ?

The above approach gives literally immediate useful guidance to content authors.

.micah




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS