do we need an ISSUE for the processing model?

hello elf.

On 2015-02-16 0:36 , ☮ elf Pavlik ☮ wrote:
>> if, as james said, the current idea is that using the class hierarchy is
>> optional, then we definitely have to model around that and make the
>> processing model more robust in our vocabulary models. i would see that
>> as very unfortunate, since a lot of the intended expressivity ('give me
>> all "Respond" and i can trust you that you will give me "Like" as well')
>> then is not something AS users can depend on. and i am still wondering
>> why the hierarchy then even is part of the normative spec. we then could
>> go back to AS1's flat model (which in my mind would be a helpful step
>> forward anyway), because that's what we essentially have.
> i wonder if you can think of a way to break this broad topic into few
> smaller bite-size chunks which we could track as official issues in wg
> tracker? imo story which you have proposed takes us into a good direction.

ISSUE-7 partly does cover it, but is more about the issue of whether 
plain AS1 JSON syntax should be supported or not. it was my first 
attempt to discuss the topic of how we can achieve interoperability 
across all implementations.

i can certainly raise another issue, but i think it really only makes 
sense if people agree that this is indeed an issue that needs to be 
discussed and resolved.

let me try to make it as simple as possible, while keeping it still is 
complex as necessary to explain the issue.

- AS is "event format" flowing through an ecosystem of AS producers, 
intermediaries, and consumers. there is no direct end-to-end connection 
between AS producers and consumers; there can be any number of 
intermediaries for aggregation, filtering, transformation, and a variety 
of other tasks.

- since i like evan's "Floop", let's continue with this example of 
having a "Floop" which is a "Like" which is a "Respond".

- one consumer subscribes to an AS-based service by saying "keep me 
updated with all "Respond" activities about a certain object, because my 
job is count those.

- in the current model it seems that if we start passing this 
subscription upstream, it is not entirely clear what is supposed to 
happen. one service may decide to *only* notify the subscriber about 
literal "Respond" activities. another service may decide to *also* 
modify the subscriber about "Like" activities. it seems that even though 
the spec defines a "Like" to be a "Respond", the processing model does 
not require implementations to treat them this way.

- what this means is that my consumer now gets some subset of what is 
really going on in terms of "Respond" activities, and there is no way 
for it to know or control how this mix is created.

- even if consumers would choose to label a "Like" explicitly as a 
"Respond", maybe intermediary implementations would have the freedom to 
discard this type because they might see it as redundant? notice that 
this can easily happen when implementations are using parsing and 
serialization frameworks that may make these decisions for them, and 
sometimes may not even have APIs to control them.

my main issue right now is that i think all of this is not really 
well-defined in the spec; at least i struggle a lot reading the spec and 
finding out what we can do, must do, and what wer can rely on and what not.

iff in fact the activity type information is optional, then i am 
wondering why it is in the spec to begin with, and what it actually means.

thanks and cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Monday, 16 February 2015 17:40:30 UTC