- From: Jim Ley <jim.ley@gmail.com>
- Date: Mon, 10 Jan 2005 17:33:36 +0000
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.
Received on Monday, 10 January 2005 09:33:36 UTC