Re: clear strategy for multiple AS2.0 serializations?

The examples are non-normative. The easiest thing to do is to simply
explicitly mark them as such.

On Thu, Jan 29, 2015 at 1:53 PM, Harry Halpin <hhalpin@w3.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/29/2015 09:32 PM, ☮ elf Pavlik ☮ wrote:
>> Howdy!
>>
>> This email acts as sort of follow up on one I've send on Dec 1st
>> and which didn't receive any replies
>> https://lists.w3.org/Archives/Public/public-socialweb/2014Dec/0002.html
>>
>>  I just picked up again work on automated testing of RDF based
>> serializations and just fixed errors in first three Turtle
>> examples.
>> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/65
>>
>> It may take me some time to fix errors in most of the remaining
>> Turtle examples and then check all the RDFa as well. But in the end
>> we will have automated tests proving that all JSON-LD, RDFa and
>> Turtle examples serialize exactly the same RDF graphs.
>>
>> After that I could take a look at possibility of contributing RDFa
>> and Turtle support to
>> https://github.com/jasnell/activitystreams.js Porting it to ruby
>> also should come as straight forward process using existing
>> libraries!
>>
>> Looking at latest WD
>> http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/
>>
>> "This specification describes a JSON-based [RFC7159] serialization
>> syntax for the Activity Vocabulary that follows the conventions
>> defined by the [JSON-LD] specification. While serialization forms
>> other than JSON-LD are possible, alternatives are not discussed by
>> this document."
>>
>> Still it provides examples in JSON-LD, Microdata, RDFa,
>> Microformats and Turtle. I think we could add little more
>> clarification about their purpose in the spec!
>
> - From the perspective of the charter, those examples could be removed.
> However, I see no harm done in keeping them (or in one or a series of
> appendices per format) if there are objections or confusions caused in
> Last Call.  Ofcourse, the Microdata/RDFa/Microformat issue remains one
> of standardizaton failure insofar as the same use-case is addressed by
> three conflicting syntaes, but that's beyond our WG's charter to fix :)
>
> Nonetheless, any fans of particular syntaxes are encouraged to build
> test-suites for any of them, although normatively we'll focus on JSON
> for CR.
>
>>
>> I have two questions here: * Does someone plan to create automated
>> tests for Microdata and Microformat examples, similar to what I
>> work on for RDFa and Turtle? * Does someone plan to contribute
>> Microdata and Microformats support to activitystreams.js or any
>> other AS2.0 implementation?
>>
>> Personally I would recommend using RDFa over Microdata. I just
>> created placeholder to capture limitations on schema.org
>> extensibility related to use of Microdata.
>> https://github.com/schemaorg/schemaorg/wiki/Extension-Mechanism#limitations-of-microdata
>>
>>  When it comes to Microformats, I would personally see more
>> interest in helping with toolchain for migrating currently deployed
>> systems to RDFa.
>>
>> IMO support for Microdata and Microformats might require some kind
>> of recommendation for *graceful degradation*, especially if at some
>> point we will get to digitally signing the content. I will happily
>> see others proving me wrong here.
>
> There is more support in the wild for both Microformats by far than
> RDFa BTW, and more RDFa (due to "Like" button I believe) than
> micordata. Thus, I think if we keep *any* of them, we have to keep all
> three. If we have to keep one, we should probably chose microformats.
> Again, people can work however they want to push their favorite syntax.
>
> I would not think that having support for one of these syntaxes would
> prevent an implementation from being conformant, but of course we
> would welcome. However, an implementation that does not accept JSON
> would be non-con-formant.
>
>    cheers,
>         harry
>
> [1]http://webdatacommons.org/structureddata/#toc3
>
>
>>
>> Cheers!
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJUyqvVAAoJEPgwUoSfMzqcml8QAIqZQPPMVl5b+3A50SXiAgu4
> OKbQwYJPPHxUQoUEF6DB+dKdzcZxus+8+APt56ymW5Q/zkgQl3hmNxLKeBsglHZH
> Zd59KvfPK6ICKajghV85vG/y6Ei+XlH3yIuFd279FbqOxNntvwaBrOsMRjMeZYHm
> hk4d3GG+N8yV2awuxi0o5ZVVpHXBkIlPcrspL4hcMdHGJSMrW2xTxIqs2V4Syc/O
> omiGHINGpKI+kr32/N3pFYEJN4Tkff2USnTihTyMJn7cquw8hjBro9nDVXPKq0x5
> GJg70UFv1sjV3N/ebdg3dakCjkyhbF0uKGmXQzuIpjcCGtRcJnwArHgaRPro26uS
> 9AnCis7t/ndrIp8goT91IxkCEMRDRHVV5ScMhnVzlZS50+5tO7GyKe/GJq7xK6/e
> Wbz3YXPn6a3O8Vgl1G+lmS4/hvCFASl3SH4rOeoiw07UotngpnUxYpuO7QeS8O3t
> uKP4ClIcgtL5ZmNa4gZ5Xdf8iMvpH4cf5M86e6Yz2dauefIkldSiPy6A7X1V1Mfp
> gcsUKT6gD6KgomHctLf57Cr+2bGMQc2zo4oU0taBO5uSXM5BeNLk9HKLbVb9H+Du
> k2TTlZ1xTmRirdRWb51fwbbbo0O/RXkrldnGKFXNTemv+yXY/9KuV92iisALf+Oi
> eFjdaO5RluPeIQ4EMcuJ
> =uJVO
> -----END PGP SIGNATURE-----
>

Received on Thursday, 29 January 2015 22:02:06 UTC