Re: Issue-14: as:Link complexity

On 04/13/2015 05:52 PM, James M Snell wrote:
> Issue-14 claims that as:Link adds to much complexity. Unfortunately,
> it doesn't explain why. Elf has brought this up in a few discussions
> but so far, he's the only one that seems to be raising objections on
> it. The argument against it is vague and seems to be purely academic
> and I recommend simply closing the issue unless there is clear
> consensus that the existing definition of as:Link is actually a
> problem *in practice*.

Hi James,

I started pull request which includes first commits which remove as:Link
from examples in core spec. We could discuss it there on concrete
examples why you see need for using it over conventional JSON-LD
embedding. It also has diagram illustrating on of the main issues I find
with it.
https://github.com/jasnell/w3c-socialwg-activitystreams/pull/98

Please notice that you and Evan didn't reply to various questions I
asked on a mailing list thread automatically created for ISSUE-14 the
tracker
* https://lists.w3.org/Archives/Public/public-socialweb/2015Mar/0062.html
* https://lists.w3.org/Archives/Public/public-socialweb/2015Mar/0202.html
* https://lists.w3.org/Archives/Public/public-socialweb/2015Apr/0009.html

We can have more concrete discussion once we get all examples from specs
properly available in JSON-LD Playground. I will also continue drawing
diagrams for those examples so we can see better graphs we construct.
Some early diagrams I already shared in
* https://github.com/jasnell/w3c-socialwg-activitystreams/issues/99

If we want to see some problem *in practice*, let's start adding to test
suite, for each case in which whenever vocab allows both as:Object and
as:Link, we create tests for *both* possible variants. But if in every
case we can model particular data by using JSON-LD embedding, I really
don't see justification for introducing as:Link.
Pull request I started should either prove no need for as:Link or
identify clear cases when we *really need* to have such construct.

Cheers!

Received on Sunday, 19 April 2015 09:49:22 UTC