[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Template Facet (was Re: Template Constructs)


Ezra Cooper wrote:
Robert,

I'm not sure I understand which problem you're trying to solve here. Are you proposing syntax for a template list? Are you proposing to layer the template-editing protocol on WebDAV in this respect?


I'm proposing a syntax for a template collection (list if you don't want to put any collections inside collections). My syntax is different in that allows properties to be placed on the collection itself as well as the templates. In my syntax, there would be no atom wrapper around template media.

I am not proposing that WebDAV be a requirement for template editing. I am positing that the WebDAV syntax for directory listing (this is what we're doing...) is better than the other proposed syntax, because the syntax I'm proposing is widely implemented, provenly extensible, and provenly interoperable.

I am proposing we use WebDAV collection property syntax as the representation we use to respond to a GET. Think of it as a machine readable equivalent to an Apache directory listing.

Working from the syntax of PaceCategoriesFacet, the introspection file would have a service element for the template facet:

<?xml version="1.0" encoding='utf-8'?>
<introspection version="0.3" xmlns="http://purl.org/atom/ns#";>
  <site title="Main Site" >
    <service name="post" href="http://example.org/reilly/post"; />
    <service name="feed" href="http://example.org/reilly/feed"; />
    <service name="categories" href="http://example.org/reilly/cat"; />
    <service name="templates" href="http://example.org/reilly/templates"; />
  </site>
</introspection>

Then, at http://example.org/reilly/templates, we'd have some kind of template list:


This is where I would use WebDAV syntax to represent what's in /templates, in response to a GET.

<?xml version="1.0" encoding="utf-8"?>
<templates version="1.0" xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-02";>
<template href="http://example.net/templates/1"; name="Entry Template" />
<template href="http://example.net/templates/2"; name="Monthly Archive Template" />
<template href="http://example.net/templates/3"; name="Index Template" />
</templates>


A GET to http://example.net/templates/1 would return a template construct [1]. Assuming vnd.joe.templatelanguage was a language that used double-brace delimiters, it might return something like this:

<template mode="escaped" type="application/vnd.joe.templatelanguage">
&lt;h1&gt; {{BlogTitle}}  &lt;/h1&gt;
&lt;h2&gt; {{EntryTitle}} &lt;/h2&gt;
&lt;p&gt; {{EntryBody}} &lt;/p&gt;
</template>


This is where my approach diverges:

I'm proposing that a response to a GET looks like this:

HTTP/1.1 200 OK
Content-Type: application/vnd.joe.templatelanguage

...vendor specific bits...

Here the template "content" is just the content of the tag. This <atom:template> tag conforms to the "content" construct in the format.

So the chain of discovery goes: IntrospectionFile -> TemplateFacet -> TemplateResource, much like IntrospectionFile -> CategoryFacet -> CategoryResource.

The request sequence is identical for clients using GET in my proposed syntax. If a server chose to support WebDAV, the reply would be in identical syntax, but the client would have the option of retrieving multiple subtrees at once, LOCKing, MOVEing, COPYing, and other advanced capabilities that are already worked out but we shouldn't require.

Robert Sayre