[whatwg] Web Forms 2.0 - what does it extend , definition of same,

[James Graham]

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 
javascript) to a valid email address, URL or date (section 2.4) will 
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 
will be possible without needing any client side javascript.

>>>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
>be simple.
>  
>
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
>body.
>  
>
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.