Roy T. Fielding wrote:
So I don't see any reason to support these features.
While I can definitely understand your argument from a purely
architectural point of view, existing blog software implementors may
(and are likely to) disagree. They're already doing this kind of stuff
[1] regardless of whether it is the right thing to do architecturally
and they're not likely going to change just because APP doesn't support
it. Most likely, they'll do what blogger has done and find some way to
hack it into the API... most likely using extension elements directly on
the atom:entry [2].
[1] http://www.sixapart.com/movabletype/docs/mtmanual_programmatic.html
[2] http://code.blogger.com/archives/atom-docs.html#extensions
So the question is: do we just ignore the fact that folks are already
doing this stuff (and potentially doing it badly)?
<?blog-enable
feature="http://example.com/blog/feature/comments-moderated"; ?>
That is blog configuration info, which cannot be in entry postings
because it splits access control. Atom should operate on resources
like a sensible implementation of HTTP, which means the resource for
accepting new entries cannot be the same as the resource for editing
blog configuration.
I disagree. The blog-enable PI is telling the blog software how to
process this particular entry. I'm not editing my weblog's
configuration, I'm just telling it how to handle this one specific entry
(specifically, "for this entry, enable moderated comments").
