[uf-rest] Fwd: [microformats-discuss] REX! Re: REST-discuss list, naming

[Dr. Ernie Prabhakar]

Hi toydi,

On Nov 1, 2005, at 8:07 AM, toydi wrote:
> Hi, yet another response to REX proposal. :)

I admire your enthusiasm, though I'm not sure I can keep up. ;-)

> After a wide adoption of ATOM in communities, maybe there would be two
> major different approaches in coming web apps implementation: 1)
> Desktop or desktop-like (e.g XUL) client software as user interface;
> 2) AJAX-like (with HTML Form, XForms, scripting) web pages as user
> interface.

For the record, I see only two viable encodings for data on the web.  
XHTML Basic (as the future of HTML) and Atom (as the future of RSS).   
In both cases, I believe they will use microformats to provide  
extensibility, though Atom may use less microformats and more  
'straight' XML.

I actually think that desktop, AJAX, and browser clients will *all*  
use one or the other of those (with my money on XHTML :-).

> In the first approach, we could see RESTful interaction and
> well-crafted representation (e.g XML) will serve and optimize overall
> client-sever communication.

Why just the first approach? And did you mean to imply that XHTML was  
not well-crafted?

> In the second approach, heavy client-side scripting allows *ad-hoc*
> authoring form creation (e.g Gmail?, TiddlyWiki?). By excuting some
> scripts while you are browsing certain web pages, the scripts will
> able to grab data in the page, create authoring form on-fly, and send
> out HTTP requests for authoring purpose.

I think you're mixing two different ideas (assuming I understand you  
correctly).  I would put it differently.

In the future:

a) Web applications will be designed around database style CRUD  
(create-retrieve-update-delete) operations.

b) There will be a way to get read-only and read-write versions of  
that data, in either list (XOXO) or table (XOXT) format.

c) The human-readable web will essentially be a shim on top of those  
applications, using CSS for presentation and AJAX (or rather "AHAH -  
Async HTML over HTTP") for dynamism.

This should all be doable with little or no scripting needed.

> Well, where we will find microformats? I think, mostly in the second
> approach? :-)

Not in my worldview -- not sure what I'm missing, or why you think  
microformats would not be needed for any of this. Are you assuming  
we'll actually agree on structured XML for every interesting problem  
space?


> However, as we can see, there will be more web pages serve their
> contents in some *alternative* versions (e.g XML, RDF, RSS, ATOM). In
> the second approach, the scripts can always request for an
> "alternative" version (mostly XML?) in order to construct authoring
> forms.

Maybe that's where we disagree.   I believe *everything* on the  
public Internet (and most of the private) will ultimately be XHTML,  
no matter where it goes (except some RSS/ATOM for legacy tools ;-).

> A question is raised: Which is faster, easier for implementation? to
> parse a microformated XHTML page, or parse an ATOM version of that
> page? (It's really a question, I don't have any pre-answer in my mind
> yet. ;-) )

Shouldn't matter much; there's some risk that XHTML pages will be  
bulkier (since they might have non-essential human-oriented text that  
needs to be skipped), but I doubt that will have a major impact.

A more important distinction, IMHO, is that the microformats approach  
uses class names or "dt" values to encode semantics, whereas XML is  
optimized around putting that in element or attribute names.  That  
does make things like XSLT transforms somewhat more complicated to  
define.

In the "goofy acronym of the week club," I suspect we'll ultimately  
see something like "XIX" ('shix', or 19 :-) aka XOXO in XML, where  
<dt>key</dt><dd>value</dd> pairs get mapped into <key>value</key>  
schema-less XML for ease of parsing.  Don't say I didn't warn you. :-)

> What i see in microformats combining with REST is a potential of
> on-fly authoring in web pages. A page as a combination of small pieces
> of resource representations, each of them are well-formatted in
> microformats. Using client-scripts, we can create ad-hoc forms and
> edit each of them on-fly, and updated contents will be sending out to
> the target resource's URL in a REST way (visual example? Maybe
> something that *looks* like TiddlyWiki? ).

Um, that should be a trivial demo, not really a major usage pattern.   
Have you seen the 20-minute Rails wiki?  The real interesting issue,  
IMHO, is decoupling data structures from presentation.Just say "no"  
to custom JavaScripts for layout and I/O. :-)

> In that way, end-users can straight away correct any typo, rearrange
> navigation menu, adding new entry, while they are browsing and viewing
> a web page. No more admin section.. and by then, why do we need a
> desktop-like client? :-)

Um, that seems more a social issue than  technical one.

> Maybe, this is another potential direction for REX?

Well, some intriguing thoughts, though I personally am more concerned  
about back-end infrastructure than trying to push a particular client  
model (beyond AHAH).

-- Ernie P.

------------
Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
Ex-Physicist, Marketing Weenie, and Dilettante Hacker
Probe-Hacker blog: http://www.opendarwin.org/~drernie/