rest/microformat-pub-protocol

[ Background Problem ]

Microformat gives meaning to small chunks of text in one XHTML document.

We can put several pieces of microformatted contents (e.g hCalendar, hAtom, hCard etc) in a single XHTML document, and both human and machine will be likely possible to understand and process each of the pieces.

Is it possible, if we (human) wish to hand-author just one of the pieces (e.g to update/delete the entry represented by that piece of hAtom), and submit it back to the remote server?

[ APP model draf-06 ]

I will highlight two resources: "Collection" and "Member", quoted from APP section 3:

"Collection"

A resource that contains a set of member IRIs.

"Member"

A resource whose IRI is listed in a collection.

In brief,

• "Collection" has a "href" IRI to accept POST to create a *new* member. See 8.1
• "Collection" has a "list-template" IRI to accept GET to *list* out members in the collection. See 9.0
• "Member" has a link *edit* IRI to accept GET, PUT, DELETE to manipulate the member. See 10.1

APP is designed for machine. Both "what" and "how" are written in draft and have to be early-bound into both client and server codes.

[ a microformat way? ]

Use "member" and "collection" classes based on the semantic in APP. The "resource" is usually in microformat. Example: hEvent is a "member" and hCalendar is a "collection". Of course, a "member" may exists in a document without its "collection".

Use <a> hyperlinks tell human "what" to do:

• click "edit" link to manipulate that particular "member"
• click "new" link to create a new member in the "collection"
• click "list" link to list the members in the "collection"

---

<code>
<nn class="member">
        <a href="[uri]"  rel="edit">Edit</a>
</nn>

<nn class="collection">
        <a href="[uri]" rel="new">New</a>
        <a href="[uri]" rel="list">List</a>
</nn>
</code>

---

Use <form> (X)HTML Form to tell human "how" to do:

• after clicking "edit" link, user receive the member, plus a form to
• update/delete it.
• after clicking "new" link, user receive a form to create new member.
• after clicking "list" link, user receive a collection of members, plus
• a form to query them.

---

Example after click "edit" link of hEvent, users may receive a XHTML:

<code>
<div class="vevent member">
<a href="[uri]"  rel="edit">Edit</a>
<abbr class="dtstart" title="20051212"> December 12, 2005 </abbr> -
<span class="summary"> Birthday Party </span> - at
<span class="location"> Home </span>
</div>

<form action="[uri]" method="post" id="vevent-form">
<textarea id="code" name="code">
<div class="vevent"><abbr class="dtstart" title.......... </div>
</textarea>
<button type="submit" id="update" name="update">Update</button>
<button type="submit" id="delete" name="delete">Delete</button>
</form>
</code>

• simple and easy for human (just read, click, type ;-)
• able to create, edit or list microcontents. (standard HTTP, XHTML)
• late-binding (e.g human will discover "what" and "how" to do by following links)
• hand authoring (use <form>. Question: human prefers plain <textarea> or h*-o-matic?)
• and still machine parsable (all are still microformat, and standard XHTML)

[ Brainstorming.. ]

Just <textarea> ?

The <textarea> is just a basic idea. More fields and h*-o-matic (with script) can be added as an alternate to help users to author a microcontent.

Where should be use?

Many blogs/forums provide "edit", "new post" links near displayed entries after the owner is authenticated. A blog user should be able to update blogroll (at the side bar), categories and entries on the same page easily by just clicking links.

So easy? It's just the same old normal way we build web pages!

That's the point, isn't it? ;-) However, I'm not sure about how machine/custom application will parse and understand XHTML <form> element. A RDF Form is out there as a machine-friendly similar version of HTML Form.