aaronpkmy favorite line in my reply is "If you are seeing similarities between jf2 and AS2 that is great, because that is *literally the goal of converging*."
kevinmarksthere are some variations in naming, yes, but given that we're already tidying up the as1 properties, changing from 'displayName' to 'name' (for example) seems reasonable
jasnellaaronpk: btw, please don't take the fact that I'm pushing back on the issues you're raising on github the wrong way. If things need to change, then I'm all for making changes. But I've been looking at this space for a very long time and have gone through many of these questions before already. Please continue to push back and make the case. I'm always open to being swayed by a good argument :-)
jasnellwe just go ahead and start creating an extension vocabulary that contains these additional types that are going to be generally useful but don't quite make the cut for core
reneAs said on github, I like the idea of having additional vocabularies that do not necessarily have to be implemented, but still guide implementers to hopefully lead to interoperability
aaronpkjasnell: yeah no problem, happy to keep discussing this. i have been searching the github issues before adding new ones to see if things have been talked about before
jasnellmuch of the conversation spans multiple forums... email chats pre WG, IRC chats, WG email, f2f conversations, etc... it's hard to keep track of where the various conversations have happened
azarothFor example, if someone has an Object that is published at time t, and that is then federated into a different stream that is made available only from time t2, should the federating stream update all of the published timestamps?
azarothIf it should be left alone, then I would propose something like: The date and time at which the object was first published or subsequently updated by the original publisher
jasnellit's not a great name and I've never been completely happy with it, but I simply carried over the definition from AS1, which carried it over from Atom
azarothaaronpk: My understanding of that is: summary is a description of the resource, and content is a representation of the resource embedded within the json (or multiple, with language maps)
jasnellaaronpk: displayName/title are essentially equivalent. In AS1, the difference between the two was that displayName is always plain text while title can contain markup
jasnellthe bias is towards "displayName" because that's what was chosen for AS1 and what most implementers currently do. displayName is not my first choice, but it's already used extensively in the wild
azarothjasnell: re published, I expected that was the case, but the definition is a little too terse to understand the interaction requirements for publishing agents. I think my email to the list is reasonably clear tho.
jasnellaaronpk: I'm not 100% against using "name" instead of "displayName", but that would be a departure from existing use in AS1, etc. Not a major concern since we've already broken from that, but still a consideration
jasnellalso, it doesn't completely eliminate the need for "title", which is the markup version. I don't want to get into a situation where "name" may or may not have markup because it needs to be there to provide a minimum fallback in case the implementation does not understand the object type
jasnellby strictly limiting name to plain text and summary to html, we at least give developers a stable target. they don't have to worry about what those might be
kevinmarks james, I think you're missing the point of jf2 a bit
jasnell Here's an alternative take on the jf2 context that positions it as an extension to AS2: https://gist.github.com/jasnell/5daa485e56440779b557
ben_thatmustbeme jasnell: thanks for looking the context over. Yeah I mass linked a lot of those values. I'm not surprised I ended up with duplicates.
rene As said on github, I like the idea of having additional vocabularies that do not necessarily have to be implemented, but still guide implementers to hopefully lead to interoperability