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

Template Constructs (was Re: ProtocolDataModel issues)


On Sep 23, 2004, at 12:02 PM, Joe Gregorio wrote:

On Mon, 20 Sep 2004 16:54:52 -0700, Ezra Cooper <ezra@xxxxxxxxxxxx> wrote:

On Sep 18, 2004, at 3:20 AM, Danny Ayers wrote:

On further reflection I noticed that the template construct is not much
different from a content construct. I don't see any problem with using
the content construct for templates. 

So do you think it would be reasonable to enable
editing templates in the following manner?

1. Create a new 'site' for the templates
2. Each 'entry' on the 'site' represents a single template.

What's a "site"? Do you mean a <site> element in the terms of PaceIntrospection? (I see the <site title="Templates"> tag now)

Different kinds of resources have different properties and different expected semantics, and overloading the notion of "entry" just forces us to tag it with what kind of thing it *really* is, and then special-case the required features. Users would want to interact with templates differently than entries, even if client software would treat them the same, syntactically.

I prefer using either a new, simple XML element to list templates [1], or WebDAV collections as per Robert's proposal [2].

Also, some implementations will want a set of templates to be tied closely with a set of entries (a "site"). Putting templates in a new <site> element would lose the connection. By contrast, putting a "template service" in a new child to <site> is more general, because it allows you to choose the @href of each site's <service name="templates"> independently. Would this be general enough for all the models in the wild?

On that note, we may want to think about getting away from this usage of the term "site." I think the <site> elements in PaceIntrospection describe distinct "content streams" (entries along with supporting content such as templates). Would "stream" be a more precise term?

Ezra

[1] http://www.imc.org/atom-protocol/mail-archive/msg00124.html
[2] http://www.imc.org/atom-protocol/mail-archive/msg00123.html