W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2005

[whatwg] Web Forms 2.0 - what does it extend , definition of same, relation to XForms, implementation reqs.

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Tue, 04 Jan 2005 09:15:46 -0500
Message-ID: <41DAA512.2080300@earthlink.net>
Jim Ley wrote:
> On Tue, 4 Jan 2005 10:23:54 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:
>>Shipping FooML over the network is not more Semantic Web
>>friendly, since software written by others are not aware of the
>>semantics of FooML.
> 
> Yet there are a huge number of known XML formats that could be used
> instead of FooML that do have well defined and well known semantics,
> these can be very sensibly used.  Masahide Kanzaki and Morten
> Friedrichsons work on XSLT transformations of RDF/XML shows how
> possible this is.

    ??? Okay, let me get this straight. Browsers MUST support 
client-side XSLT because a couple of guys did some really interesting 
work with it?

    I really don't care who's done what work. You present no obvious 
reason for using XSLT on the client instead of the server. Furthermore, 
in the event that the browser can't perform the XSLT transform (because 
it either chokes on the transform or doesn't support them in the first 
place), it really doesn't matter how well defined an XML language is. 
What really matters in a failure-to-transform scenario is whether the 
XML document is usable in most user agents without transformation. Even 
if your browser displays unknown XML like Mozilla and IE do, only the 
most intuitively designed XML languages would be of any use.

    I'd also like to point out that webmasters have far more control on 
the quality and reliability of server-side XSLT than they do for 
client-side XSLT. You can test the quality of your server-side 
transforms with your favorite browser. To do the same for client-side 
transforms, you have to test your site in EVERY BROWSER IN THE KNOWN 
UNIVERSE. That doesn't not strike me as a model you want to base your 
website on.

>>Eh? WF 2.0 is adding more declarativeness compared to WF 1.0 + JS.
> 
> Yes, but it's not adding enough to really make a difference, and is
> actually lengthening the life of the javascript mess, now I'm happy
> with that, I generally get paid for sorting out just such messes, but
> really, I'd still like to see it go away.

    If you feel that specific elements and attributes could be added to 
WF2 to decrease the use of complicated scripting, I'm sure everyone on 
the mailing list would like to hear about it. Otherwise, you're wasting 
are time like a paragraph-long run-on sentence wastes the time of an 
English teacher.

> WF2 still needs it, in fact, it's almost certainly going to increase
> the need of it, as people are going to want the features in IE and
> will start writing large shims to try and make it work.

    What, _specifically_, is "it"? Why would IE with working WF2 support 
require more additional Javascript than another browser?

> Scraping the presentation layer to ensure there's no spamming, and
> it's consistent with the data layer is a much better problem for
> search engines that trying to infer the semantics from the
> presentation layer, that's hardly been a great success.

    You must be talking about XForms or something, because there a 
dozens of XML-based languages that are MORE presentational than HTML. 
All you have to do to figure that out is visit the inappropriately named 
http://xul.sf.net.

    Really, though, I think this kinda sounds like people are arguing 
for using XSLT as some kind of client-side emulation layer. Personally, 
I think you might as well be using a Java plug-in...
Received on Tuesday, 4 January 2005 06:15:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC