Further Shaping the Well Formed Log Entry.

| No Comments

As the discussion on Sam Ruby's Well Formed Log Entry wiki has progressed a certain amount of consensus and clarity is forming. Here is my summary of the key requirements being discussed.

Post date. There are 3 types of timestamps used in weblog systems today. Created-on, Last-Modified and Publication timestamps. Publication timestamp (or post date) is the most important and thereby required element of a well formed log entry. It allows an author to control the ordering of log posts which are ordered chronologically by nature. The publication date is similar in nature to the data on a newspaper or magazine where fo r editorial reasons the content is commonly published before the date on the cover. Created-On and Last Modified timestamps are optional and part of an optional extension module called Authoring which is ties into versioning. The created-on and last-modified dates of the actually representation (the HTML produced when a log entry and template are merged) are outside of the scope of the discussion though they may be used in substitution if a post-create and post-last-modified data are not tracked by the system in use.

Author. One and only one author is required in a well formed post. The author can be a system such as a Wiki or CVS. While post may be developed collaboratively with multiple individuals participating only person or system is the primary author with the remainder optionally listed as contributors.

Permalink. The discussion seems to be nearly consensus though it doesn't seem to have been totally reached. Sam Ruby one of the requirements for the discussion as must be on the Web. Tim Bray wrote a nice post on this topic and versioning that I think (there seems to be some confusion to what the other Tim actually meant) nails it. He writes A log entry's primary identifier should be a URI, just because this is about the Web and if you have a URI you're on it, otherwise not. Permalinks are URIs, but URIs are not necessarily permalinks so some clarification is needed. I think that a permalink should be required and is the primary identifier of a well formed log entry. Bray does seems to indicate similar thinking when he writes In the world of weblog entries, I can't imagine why you'd use an identifier that doesn't double as a locator, so I don't think URNs are particularly relevant. URNs don't necessarily resolve to anything necessarily, so is Bray suggesting that URIs must be permalinks or should be permalinks or neither? Here is the confusion amongst the group. I agree with his conclusion that a URI (permalink?) along with version info that uniquely identifies a well formed entry. The version info is a string whose value can be determined by the author and/or system developer – modified date, digest hash or sequential number.

Content. This area still is the least defined area of the whole discussion. There are still many issues left open and unresolved. Someone better articulated my previous questions and concerns on the context of the content. The answer is it depends whether the log entry is being used in the context of an internal or external model. Here is the explanation as it read as I write this:

An internal model is used by the source or provider of an entry and contains the entire breadth and depth of the entry.

An external model is used to convey information about an entry, possibly up to including the entire breadth and depth of an entry. For sets of entries, an external model may represent sets of entries differently depending on the purpose of the set.

This distinction helps to answer questions like is the content in the entry or available at the permalink, does the permalink point to a rendered presentation of the entry (HTML, image, etc.) or does the permalink point to the entry data (see content and PermaLinks ), and should contact information for the publisher be included.

The answer could be both, depending, then depending can be further clarified.

Internal models are most often used in content-management APIs (RESTlog, CommentAPI, BloggerAPI, MetaWeblogAPI), external models are most often used in meta-data and syndication APIs (TrackBack, RSS, aggregators, portals).

Well put. (I wish I knew who wrote it. The joy of the wiki. Update: The joy of the blog. It was Ken MacLeod.) I think it goes to the heart of why content is the most vague and has the most open issues. It hard to reach consensus when it depends on the context and model in use.

I'm not much for the abstract and have a tendency to start in on concrete application when studying the theoretical. This exercise has been fascinating and sometimes quite a brain twisting learning experience for myself. Fighting my tendencies has been the hardest part. With that bias disclosed, I think its time to move the conversation forward and drill down deeper into the context/models of a well formed log entry.

In related news, Tim Bray contributes another great post on the promise and peril of RSS. All the reason why we need to do this work.

<p>As the discussion on <a href="http://www.intertwingly.net/wiki/pie/FrontPage">Sam Ruby&#39;s Well Formed Log Entry wiki</a> has progressed a certain amount of consensus and clarity is forming. Here is my summary of the key requirements being discussed.</p>
<p><strong>Post date.</strong> There are 3 types of timestamps used in weblog systems today. Created-on, Last-Modified and Publication timestamps. Publication timestamp (or post date) is the most important and thereby required element of a well formed log entry. It allows an author to control the ordering of log posts which are ordered chronologically by nature. The publication date is similar in nature to the data on a newspaper or magazine where fo r editorial reasons the content is commonly published before the date on the cover. Created-On and Last Modified timestamps are optional and part of an optional extension module called <q>Authoring</q> which is ties into versioning. The created-on and last-modified dates of the actually representation (the HTML produced when a log entry and template are merged) are outside of the scope of the discussion though they may be used in substitution if a post-create and post-last-modified data are not tracked by the system in use.</p>
<p><strong>Author.</strong> One and only one author is required in a well formed post. The author can be a system such as a Wiki or CVS. While post may be developed collaboratively with multiple individuals participating only person or system is the primary author with the remainder optionally listed as contributors.</p>
<p><strong>Permalink.</strong> The discussion seems to be nearly consensus though it doesn&#39;t seem to have been totally reached. Sam Ruby one of the requirements for the discussion as <q>must be on the Web.</q> <a href="http://www.tbray.org/ongoing/When/200x/2003/06/18/EntryID">Tim Bray wrote a nice post on this topic and versioning</a> that I think (there seems to be some confusion to what <q>the other Tim</q> actually meant) nails it. He writes <q>A log entry&#39;s primary identifier should be a URI, just because this is about the Web and if you have a URI you&#39;re on it, otherwise not.</q> Permalinks are URIs, but URIs are not necessarily permalinks so some clarification is needed. I think that a permalink should be required and is the primary identifier of a well formed log entry. Bray does seems to indicate similar thinking when he writes <q>In the world of weblog entries, I can&#39;t imagine why you&#39;d use an identifier that doesn&#39;t double as a locator, so I don&#39;t think URNs are particularly relevant.</q> URNs don&#39;t necessarily resolve to anything necessarily, so is Bray suggesting that URIs <em>must</em> be permalinks or <em>should</em> be permalinks or neither? Here is the confusion amongst the group. I agree with his conclusion that a URI (permalink?) along with version info that uniquely identifies a well formed entry. The version info is a string whose value can be determined by the author and/or system developer &#8211; modified date, digest hash or sequential number.</p>
<p><strong>Content.</strong> This area still is the least defined area of the whole discussion. There are still many issues left open and unresolved. Someone better articulated my previous questions and concerns on the context of the content. The answer is it depends whether the log entry is being used in the context of an internal or external model. Here is the explanation as it read as I write this:</p>
<blockquote>
<p>An internal model is used by the source or provider of an entry and contains the entire breadth and depth of the entry.</p>
<p>An external model is used to convey information about an entry, possibly up to including the entire breadth and depth of an entry. For sets of entries, an external model may represent sets of entries differently depending on the purpose of the set. </p>
<p>This distinction helps to answer questions like <q>is the content in the entry or available at the permalink</q>, <q>does the permalink point to a rendered presentation of the entry (HTML, image, etc.) or does the permalink point to the entry data</q> (see content and PermaLinks ), and <q>should contact information for the publisher be included</q>. </p>
<p>The answer could be <q>both, depending</q>, then <q>depending</q> can be further clarified. </p>
<p>Internal models are most often used in content-management APIs (RESTlog, CommentAPI, BloggerAPI, MetaWeblogAPI), external models are most often used in meta-data and syndication APIs (TrackBack, RSS, aggregators, portals). </p>
</blockquote>
<p>Well put. (<del>I wish I knew who wrote it. The joy of the wiki</del>. <strong>Update:</strong> The joy of the blog. It was Ken MacLeod.) I think it goes to the heart of why content is the most vague and has the most open issues. It hard to reach consensus when it depends on the context and model in use. </p>
<p>I&#39;m not much for the abstract and have a tendency to start in on concrete application when studying the theoretical. This exercise has been fascinating and sometimes quite a brain twisting learning experience for myself. Fighting my tendencies has been the hardest part. With that bias disclosed, I think its time to move the conversation forward and drill down deeper into the context/models of a well formed log entry.</p>
<p>In related news, Tim Bray contributes another great post on the <a href="http://www.tbray.org/ongoing/When/200x/2003/06/19/RSS4All">promise and peril of RSS</a>. All the reason why we need to do this work.</p>

Leave a comment