[whatwg] Web Forms 2.0 - what does it extend , definition of
same, relation to XForms, implementation reqs.
Matthew Raymond
mattraymond at earthlink.net
Tue Jan 4 06:15:46 PST 2005
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...
More information about the whatwg-whatwg.org
mailing list