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

[James Graham]

Jim Ley wrote:

>On Tue, 11 Jan 2005 10:09:59 +0000, James Graham <jg307 at cam.ac.uk> wrote:
>  
>
>>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. 
>>    
>>
>
>I'm looking for use cases
>
If a use case isn't a case where it would be used, and be beneficial, 
what is it?

>, I note you fail like everyone else to
>actually deliver one.  The ability to restrict input client side to
>your productions exists, there's no missing functionality on the web
>today, certainly data entry in such systems already does it!
>  
>
Indeed. But doing it client side via declarative markup rther than 
scripting has several advantages:
1) A well debugged, easy to use, implementation. Better surely than a 
thousand slightly different, slightly broken implementations.
2) A better UI. An <input type="date"> can provide me with a calendar. 
An <input type="email"> can prefill my email address or offer my system 
address book
3) Better accessibility. A non visual client may be able to use the 
extra information about the type of information required to offer a 
better interface.

>  
>
>>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.
>>    
>>
>At the same time, things like email are less rigourous validation than
>is currently used (even if the email validation is almost always
>incorrect syntactically) since they generally test that the TLD is a
>valid one.
>  
>
Which is still quite possible in the new system. One would require 
javascript for this additional test to be performed client side but 
knowing that the email adress is syntatically correct before trying to 
test whether the TLD exists. If such a test is to be performed server 
side, one could use Web Apps 1.0's XmlHttpRequest to provide the 
required communication so that the page could offer a seamless user 
experience, with no need to load seperate error pages after every 
mistake (so damaging history, caches, etc.)

>>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.
>>    
>>
>
>Exactly, which is why it makes sense to create web-application
>language that can consume more complicated formats directly, then it's
>not an extra page to provide and an extra level of abstraction, you
>are simply rendering the semantic data.
>
I don't understand at all how that would work. Given that the back end 
will always be a database, and that the front end will always need 
elements other than the semantic data (prose, buttons, etc.) what you're 
saying doesn't make sense. There will always be a seperation between the 
data and the front end and making the data avaliable in some 
data-specific semantic format at the front end will always be harder 
than just presenting a display of the data.

>  It's a good use case, with
>the current HTML crop we have to create n documents for each view
>iCal, voice, HTML etc.  If web-application languages had things such
>as XBL, we would be creating transformations from a single rich data
>source.
>  
>
Eh? This makes no sense. If I have a data source I can already present 
as many views of the data as I want (by "transforming my rich data 
source") and make each view avaliable to clients that understand it. As 
far as I can tell, you haven't actually proposed anything that isn't 
already possible. If you have in fact proposed something new, can we 
have details of how it would work please? You've also carefully snipped 
all the reasons that, even though underlying data can already be made 
avaliable to clients, few web apps choose to do so i.e. the reason that 
any technology like the one you describe would be ignored in many 
situations.

>>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).
>>    
>>
>
>I understood the topic at hand is improving the robustness and ease of
>authoring of web-applications?
>
Indeed. So why are you talking about technological pipe dreams that, 
even if realised, would be ignored by many users (because it would be 
contrary to their goals as a business, for example)?

>>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. 
>>    
>>
>
>This isn't true, the questions are very much linked, if you're
>learning disabled and use a symbolic language like BLIS as your
>interface to the world, no amount of HTML tweaking is going to make a
>service accessible, a rich data format does make it possible.
>  
>
But the question of whether that rich data is avaliable is totally 
orthogonal to the question of whether the Web App front end is written 
in HTML or not. There is no way to force someone with data to make it 
avaliable. It is, however, possible to make the front end to the data 
usable by a many (perhaps not all but certianly a large number) of 
people. That's the focus because it's the only realistic goal.

> Real accessibility benefits
>for the harder to reach members aren't being addressed here.
>  
>
You have oppertunity to comment on accessibility issues in the mailing 
list. However instead we seem to having all this meta-discussion. If you 
are convinced that WHATWG work is of no use (or won't be used, which is 
the same thing), there is little point in your being here. If you are 
convinced it is of some use but not perfect then you are quite correct. 
One simply can't solve all possible problems when a design requirment is 
backwards compatibility. If you don't think backwards compatibility is a 
necessary design requirment, there is little point in your being here 
because it is undoubtedly much easier to create a cool technology that 
solves a bunch of problems with a clean sheet of paper.

>>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.
>>    
>>
>
>I assume you're stating this as a fact having reviewed the currently
>available solutions?  Some of which are being used by an awful lot of
>developers using good frameworks that work well.  There's even W3c
>standards on some of it.  Could you point me at some justification for
>your statements?
>
Technologies such as RDF/XML are prime examples of standardised, 
extensible and unwieldy formats that are hard to use and understand. 
Sure, that's a metaformat rather than an actual way of communicting 
specific data but it is exactly those properties that lead to it being 
bypassed by real data communicating formats such as Atom and lead to 
existing RDF-based solutions such as FOAF gaining competition from much 
simpler, easilly implemented formats such as XFN. It is also true that 
just about every format that is widely used and standardised is abused 
in some way - HTML (when used for simple documents) is an obvious 
example, as is RSS.