Feeds aren't activitystrea.ms compliant about django-activity-stream HOT 7 CLOSED

Are you talking about the streams themselves or the actual Atom feeds?

from django-activity-stream.

I mean the feeds, but I may just be confused. I was looking at the admin user's incoming feed in the example project, and saw that the Atom Activity namespace wasn't specified and no <activity> elements appeared. But again, it's entirely possible that I don't understand the spec and all of this is irrelevant.

from django-activity-stream.

i see what you are saying and it sounds like a good idea. it would b stupidly simple to extend the atom feeds to include the activity namespace. my hesitations are that 1) the atom activity spec is just a proposed draft and not a final rfc or anything official 2) would that mean that it could break atom parsers? this seems like a good idea to implement in the future but im open for suggestions/patches/ideas.

from django-activity-stream.

Compliant Atom parsers should ignore the extra markup: "When unknown foreign markup is encountered in a Text Construct or atom:content element, software SHOULD ignore the markup and process any text content of foreign elements as though the surrounding markup were not present." Your hesitation about implementing a draft spec is reasonable, although presumably any changes won't be so fundamental as to make the work wasted. I'll be taking a look tomorrow night and maybe I'll take a crack at a patch.

from django-activity-stream.

In order to bring the feeds into compliance, it's going to be define verbs differently, because:

1. Verbs are associated with URIs, like: http://activitystrea.ms/schema/1.0/post
2. The verb associated with an action may be subclassed from a (or several) more generic verb(s), and each applicable verb should be displayed in the feed, so that parsers that understand one of the less specific verbs can still parse the entry.

It seems like it will be necessary to define a data structure containing all of the verbs to be used by an application, perhaps using key value pairs of {'URI':'human-readable verb phrase'}. The data structure should also define a hierarchy so that for a given verb entry, it is possible to access parent entries at each level.

from django-activity-stream.

It sounds like a good thing to categorize, but I also want people to have individual, custom verbage. Maybe this could be a verb_category (Char/IntField using choices ripped from the activitystream.ms schemas) AND a verb (CharField). That seems do-able and i could help you develop a patch for that. Diving deeper down the rabbit hole, we should also categorize in the same manor Object Types (subjects/actors) defined in section 3.2. This one seems much harder since its generically dealing w/ Django models, but just food for thought.

from django-activity-stream.

I thought some more about this, and maybe the solution is to make verb an array of dicts of the form: {'verb':'posted a notice', 'verb-type':'http://activitystrea.ms/schema/1.0/post'}. The verb-type could be omitted and default to something sensible (like 'post' or nothing) and the storage & organization of the types could be up to the application.

For object types I was thinking that models could optionally specify a get_object_type method to do the right thing, and otherwise to default to the model's __doc__.

from django-activity-stream.