Experience report: Our implementation of comments for AOL blogs
includes the count information in a proprietary extension
(aj:commentCount), precisely because we need the information for UI
purposes. We've found it useful and we'd like to use a more standard
extension to help enable interoperability.
The one issue we've had with it was with a partner who used a checksum
on the retrieved file to determine if something has 'changed' in the
feed. We explained how they can use the update timestamps for that
purpose and everything was solved.
I don't see any issue with these attributes.
-John
James M Snell wrote:
I find it utterly amazing that there is so much contention over two
optional attributes that serve a purely informational purpose. If a
feed publishers includes them, and a particular feed consumer currently
doesn't see a use for them, that feed consumer can ignore them and
continue processing the feed with ZERO loss of function.
"I've started thinking about my schema not as the definition of what
this system needs right now but as the definition of what the data
should look like if it's present instead."
- Tim Ewald, "Making everything optional" [1]
There are some folks for whom the attributes will be useful. I know,
for instance, that SixApart has found a use for them in some stuff they
are doing with Friendster. I have also used the attributes in a
browser-based feed aggregator I've been toying around with. Others may
not find a use for the attributes at all. That's ok. If you don't have
a use for them right now, **ignore them**. If someone implements
support for the attributes and finds that they cause some sort of
significant interop issue, that's ok, that's why the IETF process is
iterative. "Proposed Standards" are not set in stone. They can be
changed if implementation experience demonstrates that change is necessary.
Regarding whether this should be Experimental or a Proposed Standard, I
will defer to the judgement of the IESG, however, RFC2026 has the
following to say about "Proposed Standards":
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
...
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
Seems appropriate to me.
Regarding how The Evil Attributes could be used? Given two replies links,
<entry>
...
<link rel="replies" href="1" title="Comments"
thr:count="10" thr:when="2006-12-12T12:12:12Z" />
<link rel="replies" href="2" title="Trackbacks"
thr:count="5" thr:when="2006-11-11T11:11:121Z" />
</entry>
You can display two buttons in a GUI.
"Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006)"
"Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006)"
- James
[1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx
A. Pagaltzis wrote:
* Robert Sayre <[EMAIL PROTECTED]> [2006-05-17 07:25]:
I would have said this should go Experimental,
+1
We can wait and see what problems crop up in practice with the
contested attributes, and whether extensibility according to Sec
6.4. ff (or lack thereof) turns out to be paramount or, to borrow
Tim’s turn of phrase, a molehill.
If it works out, just reissue it; if not, there’s room to go back
and fix it.
Sounds reasonable enough to me.
Regards,
