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

Re: ProtocolDataModel issues


On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote:

Ezra Cooper wrote:
Here are some kinds of resources that I'd be interested in modeling in Atom:
* Non-entry resources (images, etc.)

PaceSimpleResoucePosting takes care of this, right? I guess the only remaining question is how a client locates them, or what resource has these non-entry resources as a many: property.

Yes, I think so. I don't see any need to model these as anything other than a generic web resource.

  * Templates
      - template body
      - name
      - target filename


Could this be rephrased as
- content
- MIME type
- title
- URI

Is "URI" the for the XML Atom resource, or for the public HTML file?

I was groping for a way to determine the URLs of the public HTML files. We could certainly have a static URL field to be used for templates that only generate one HTML file. However, a common scenario is that where one template will generate many HTML files, at URLs determined by a given pattern. If we wanted to get fancy, we could make the "URI" field MIME-typed, like the content field, so that you could use a template language to specify the scheme of URLs generated by that template. Clients could treat it as a vanilla text box, or they could provide UI help for certain URL-template languages.

  * Authors (Principals)
  * Categories


What properties does a category need?
- name
- URI

Do we want to model categories as hierarchical or flat, or as DAGs? If flat, then hierarchical tools might have to write out long path names for their categories. Do we stop at having a single parent for each category, or can we allow several parents (giving rise to DAGs)? Looks like there are at least two or three possible models for categories.

I favor a hierarchical model, possibly with a fallback for tools that don't want to deal with hierarchies. For the fallback, it might be enough just to make sure that each category has a unique human-readable name so that users can select a category without seeing the hierarchy.

* Weblog-level configuration
Can we agree on at least a few weblog-level configuration fields that would be useful to be treated by the protocol? Such as title, description, HTML URL, maybe timezone...

What constitutes Weblog-level? Is there a vague agreement here?

What constitutes a "weblog"? The question of a generation. Here I'm thinking of something that corresponds to a "feed" but the "feed" is the reader's-side view and this entity would be the publisher's-side view. A feed is something fed to you; this is more like cooking.

Maybe this is the same as the PostURI; maybe when you GET the PostURI, you get this feed-level resource.
To rephrase that, suppose the PostURI is really a "weblog resource" or an "editable feed resource." When you POST to that resource, you're posting a new entry into the feed. When you GET that resource, you get the feed-level metadata (or even the full feed). This resource would also be the place where feed configuration extensions could be made.

This would also be a place to offer links for discoverability of the other "lists": like the list of available categories. Currently, in TypePad, to get a list of available categories, you GET a URL ending in "/t/atom/weblog/blog_id=<blog id>/svc=categories". Rather than set a standard form for this URL, I'm proposing it be chosen by the server and listed in the uber-discoverability resource which can be GOT at the PostURI.

I like the idea of hiding most of the discoverability links at this feed-level resource, as opposed to dragging them down the front street on the HTML page. As has been discussed before, in a system with multiple blogs per author, author X might not want to reveal that she authors blogs B and C in addition to A; but she wants her posting client to recognize this so that she can move amongst them with ease. A GET on the PostURI would be authenticated.

Alternatively, instead of offer links to other lists, we could bundle all that data into the result you GET at the PostURI.

Also at the feed level in the protocol: how about a link to the server's help pages? In various places in a posting client, you might need to refer to docs for, say, the server's template language. The client could display an icon that links to the help link provided by the server. This would be an optional element at the weblog/feed level.

It feels wrong to call this *thing* a "feed" on the protocol side, since it is editable. I don't want to be weblog-specific, either. What can we call an editable feed? Can we distinguish it from a "feed" per se, which is the thing documented over at "Atom Format" [1]?

Ezra

[1] http://ietfreport.isoc.org/idref/draft-ietf-atompub-format/