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

[Jim Ley]

On Mon, 10 Jan 2005 17:07:32 +0000, James Graham <jg307 at cam.ac.uk> wrote:
> Jim Ley wrote:
> 
>>On Mon, 10 Jan 2005 14:22:46 +0000, James Graham <jg307 at cam.ac.uk> wrote:
> Isn't that a bit like saying "If you ignore the email part of GMail..."?

No it's not, because purchasing is completely irrelevant to Mathews
benefit of not using script in the web-application, since the only
benefit he gave was search engine discovery (indeed that's the only
benefit given anywhere in recent threads).

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.

> >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.

> In this case, the UA has no need to ever come into
> contact with the RSS, just with the HTML (or XForm or XUL or whatever).

but that's bad, it puts extra layers in the system if we don't need
another transformation where information is lost we shouldn't have it,
we're supposedly building something for the future here - email
transformed to javascript, transformed to HTML, transformed to a
particular CSS based rendering - introduces extra points of
complication, and we lose semantics at each level.  This isn't a good
idea!

> 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.

>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.

> The problem for language
> design is that there's no way to provide those semantics for every
> possible format of information that one might want to transmit. 

How do you mean?  it may mean private vocabularies for certain things,
but most web-applications are well covered by some sort of common
format for the majority of their data.  Even social networking sites
have agreed formats for it, it's really not difficult.

> 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.

Jim.