[whatwg] Web Forms 2.0 - what does it extend , definition of same,
jg307 at cam.ac.uk
Tue Jan 11 02:09:59 PST 2005
Jim Ley wrote:
>The web-forum and comment on data version of web-application is very
>well addressed in existing HTML, could you provide exactly how the
>WHAT-WG work is solving particular use cases in this scenario - yep,
>I'm still asking for use cases months down the line, because I'm still
>not hearing any.
Reread section 2 of the Web Forms spec for some of the more obvious
improvements. The ability to restrict input (client side, without
make data entry in such systems easier for users. The required attribute
(section 2.7) provides a convenient mechanism for indicating that users
cannot post without a valid email address (for example). Again, this
>>>Because consuming semantic mark-up means that user agents can
>>>understand the semantics of the mark-up
>>I understood that it was the web application itself that ws consuming
>>the markup, not the UA.
>The ideal is both, users with different needs have big problems using
>generic UA's by providing semantic mark-up, it's trivial to create new
>views on the same data - think how easy Mathew Somervilles Accessible
>Odeon scraping would've been had they based their system on iCal.
Indeed. They could have used HTML 4's <link rel="alternate"> to point to
the iCal data from the HTML page. Sadly, the convenience of building up
HTML directly from the underlying database (not to mention the
incompetence of Odeon) meant they didn't feel the need to insert an
extra layer of abstraction between their db and the web page.
>>As a user I know the from address because it has the string 'from:'
>>before it (or some other such thing).
>In a particular rendering you know that, if you have problems
>accessing that particular rendering there's nothing you can do other
>than hope someone who can understand is able to "trivially scrape" the
>information. Something of course that breaks as soon as the format
>changes. If they used standard semantics for the transport that would
But that's a parallel problem to the problem of a sutiable language for
creating a Web-based interface to the data (the actual topic at hand).
It is already quite possible to provide the raw data in a standard
format (where one exists). For example Google allows pop access to GMail
accounts, Amazon provides a web-services API to its data, some eblogs
provide full-content RSS/Atom feeds, and so on. So you're trying to
solve a solved problem. Importantly, however, it's a problem that many
people who control the data don't want to solve, at least not as a
requirment for building a web-based front end. Hotmail allows access to
the underlying mail data but only on condition that you pay or use their
proprietry client (Outlook Express). Google offers web search results
via a web API but only for money. Many weblogs offer only partial
content feeds often because the graphics and presentation are as much a
part of the skillset that the author is trying to display (as a graphic
artist, for example) as the textual content itself is. In all these
cases, the author has an excellent business reason to restrict the
extent to which the content is avaliable in a standard, easilly reused
format and so they would ignore any format which tried to force such
distribution of the underlying data.
>>in most situations
>>that's not what I want to do; I just want to read my email.
>Of course, in almost all situations providing a jpeg would be fine
>too, the motivations for semantic mark-up etc. aren't based on the
>most situations, they're based on the ability it gives to enable users
>who aren't covered by that standard solution.
Not at all. There are two questions here - can we make the front ends to
web documents and applications accessible and can we make the underlying
data avaliable for repurposing. A JPEG soultion fails to solve the first
problem and the second. HTML, XForms, XUL and so on try to solve the
first problem but have little impact on the second (with the exception
of <link rel="alternate"> and any other similar devices). The second
problem is largely already solved (for those who would have the
solution) - one just sets up a URL containing the data or a web service
API for interacting with the data.
>>There's not going to be an existing langauge that meets my requirements
>>so I have to invent one. At the point that I've invented a language,
>>semantics are irrelevant because no general purpose client application
>>is going to know them anyway.
>No, because they'll be a lot of commonality, and as long as your base
>language is extensible enough to allow re-use of the common elements,
>then you have no problem, a user agent that can understand "email
>subject", "email body" won't die if it also has "email from" it may
>not make use of it, but there's value in the email subject and email
But making the base langauge extensible enough that it can be used for
all possible situations also makes it unweildy, unoptimised and hard to
use or understand. In these situations developers (especially ones who
have no interest in interoperability e.g. those working for vendors of
proprietry products) will generally invent their own language that meet
these needs directly rather than waste time or effort trying to
understand a very complex but powerful language that may eventually
turn out to not allow for the killer feature of their product. Or they
go with the language but don't use it correctly (through malice, lack of
faetures, or lack of understanding) and produce something that appears
to be interoperable but isn't quite. This has already happened for HTML,
it alredy happened for RSS and Atom and it will probably happen with any
other langauge designed for a specific task.
Sure I would like it it everyone communicated everything freely using
standard languages correctly. Realistically, it isn't going to happen.
More information about the whatwg