W3C home > Mailing lists > Public > public-socialweb@w3.org > January 2015

Re: clear strategy for multiple AS2.0 serializations?

From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
Date: Fri, 30 Jan 2015 13:51:23 +0100
Message-ID: <54CB7E4B.3010906@wwelves.org>
To: public-socialweb@w3.org
CC: Harry Halpin <hhalpin@w3.org>
On 01/29/2015 10:53 PM, Harry Halpin wrote:
> On 01/29/2015 09:32 PM, ☮ elf Pavlik ☮ wrote:
>> 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 didn't refer at any point to current adoption of those three HTML
based serializations. I just wanted to emphasize that RDFa provides very
straight forward round trip conversion to JSON-LD and Turtle while
Microformats and Microdata do NOT.

I will propose a short explanation of serializations used in examples
which we can include in the spec
https://www.w3.org/Social/track/actions/34

Please also note here overdue ACTION for review of microformats examples
https://www.w3.org/Social/track/actions/26
I just proposed in that action delivering review of first 10 examples
ASAP since it may take very long time to review all of the examples in
both documents.

I also consider to propose removing from the spec examples in all
serializations which don't have automated test comparing them against
normative JSON-LD version. I see lack of tests as evidence for the fact
that those serializations do NOT provide feasible way to handle them
programmatically. Once again, delivering automated tests can prove such
reasoning invalid :)


Received on Friday, 30 January 2015 12:51:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:14 UTC