W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2016

Re: Reviewing Social Web Specs

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 24 Jun 2016 20:24:50 -0400
To: "Phillips, Addison" <addison@lab126.com>, "Richard Ishida, Staff Contact, i18n WG" <ishida@w3.org>
Cc: "public-socialweb@w3.org" <public-socialweb@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <576DCF52.2060600@w3.org>
With a little work, our specs would let me signal "Like" on this email, 
without having to give a thoughtful reply.  :-)

       -- Sandro

On 06/24/2016 08:13 PM, Phillips, Addison wrote:
>
> Thanks Sandro.
>
> But they're not stable, then.    I guess in theory we could try to 
> notice, for each of our many specs, when we're down to issues that 
> somehow don't bear on i18n, and then ask for i18n review, then notice 
> when we're down to issues that somehow don't bear on a11y and then ask 
> for a11y review, and so on with each kind of horizontal review for 
> each spec...      I've been through this a dozen times in as many 
> years, and I've still no idea how to do it, other than wait until all 
> the issues are closed. Perhaps I'm a slow learner.
>
> That’s true: they’re not stable. But often the interesting I18N 
> discussions are actually the best time to involve the I18N community. 
> What makes me nervous is approaching a WG whose spec is in CR and 
> going “oh, you didn’t think about tagging all of X with a language” or 
> “your requirement doesn’t allow international text” or worst of all 
> “you’re missing a feature”. WGs and implementers are not happy to have 
> to go back to the drawing board: there is disincentive to getting to 
> the right solution.
>
> But it’s also true that when a spec is unstable, the comments are more 
> distracting and less targeted and you’re busy trying to get consensus 
> on Things That Matter (not that I18N doesn’t matter, but…)
>
> As a WG, we’ve been trying to make the process a little more 
> self-service. For example, we’ve started to harvest our comments and 
> build a “best practices” document [1] to work as a kind of mini 
> checklist. If your spec already bears our considerations in mind, then 
> presumably we’ll only have to look at the truly novel stuff.
>
> Ultimately, if we have six or so months, as here, we aren’t going to 
> be rushed and do a haphazard job for you. And presumably, if we do the 
> review in an efficient way, a lot of that time can be used in 
> responding to our comments.
>
> Ultimately, I’ve been doing this dozens of times a year for many years 
> and **I** don’t think there is a panacea. I don’t think you (or I) are 
> a slow learner. Instead I think that “just right” varies by working 
> group and spec. And my main concern is: that our WG have enough time 
> to do a good job for you, but not bog you down in an ocean of 
> pointless process.
>
> Kind regards,
>
> Addison
>
> [1] https://www.w3.org/TR/international-specs/
>
> *From:*Sandro Hawke [mailto:sandro@w3.org]
> *Sent:* Friday, June 24, 2016 2:37 PM
> *To:* Phillips, Addison <addison@lab126.com>; Richard Ishida, Staff 
> Contact, i18n WG <ishida@w3.org>
> *Cc:* public-socialweb@w3.org; public-i18n-core@w3.org
> *Subject:* Re: Reviewing Social Web Specs
>
> On 06/24/2016 05:00 PM, Phillips, Addison wrote:
>
>     Hello Sandro,
>
>     Thank you for this note. I’ll be updating our review radar [1]
>     shortly with this information.
>
>
> Thanks, Addison
>
>
>     Do you have specific schedules or deadlines for any of these
>     documents that we should be mindful of?
>
>
> Our only hard deadline is the group will be shutting down at the end 
> of the year.   I have fantasies of PR at the end of the summer.  So, 
> obviously, the sooner the better, if we're to have a chance to do 
> anything about it.
>
>
>     I suspect that we will want to review all of these. I must point
>     out that reviewing a document that is already in CR or with very
>     short time before CR is not ideal. Please consider requesting
>     reviews closer to FPWD in the future.
>
>
> But they're not stable, then.    I guess in theory we could try to 
> notice, for each of our many specs, when we're down to issues that 
> somehow don't bear on i18n, and then ask for i18n review, then notice 
> when we're down to issues that somehow don't bear on a11y and then ask 
> for a11y review, and so on with each kind of horizontal review for 
> each spec...      I've been through this a dozen times in as many 
> years, and I've still no idea how to do it, other than wait until all 
> the issues are closed.  Perhaps I'm a slow learner.
>
> MEANWHILE, that reminds me, we did notice one i18n issue with AS2, 
> which I wrote to Richard about on May 10.  In retrospect, I should 
> have included a larger list of recipients.   I wrote:
>
>
>
>     The Social Web WG expects to have 2-5 specs going to CR in the
>     next two months.
>
>     One of them has an I18N issue we noticed.   The others, none yet.
>
>     The issue we notice is in Activity Steams.  This is basically a
>     syndication format/vocabulary, for people to publish what they've
>     been doing online.   Liking things, checking in at locations,
>     unfriending people, etc.  It includes a standard vocabulary for
>     common things, but anticipates lots of extensions.
>
>     It uses a constrained subset of JSON-LD as its syntax. So that
>     limits how it can encode lang information.  And within the JSON-LD
>     limitations, we've chosen some more limitations.   Specifically,
>     we've allowed exactly one way to provide lang tags.    It looks
>     like this:
>
>     No language tag:
>
>     { ...
>       "content":"A <i>simple</i> note"
>     }
>
>     With language tags:
>
>     {...
>        "contentMap":{
>           "en":"A <i>simple</i> note",
>           "sp":"Una <i>simple</i> nota"
>        }
>     }
>
>     This should work, but it does not allow any kind of defaults.  Any
>     property that doesn't use a lang map has no language information. 
>     Unfortunately we're unable to find any reasonable way to allow
>     defaults.
>
>     See discussion at
>     https://www.w3.org/wiki/Socialwg/2015-12-02-minutes#Issue_251
>
>
> Hoping that helps,
>
>      -- Sandro
>
>
>     Best regards (for I18N),
>
>     Addison
>
>     Addison Phillips
>
>     Principal SDE, I18N Architect (Amazon)
>
>     Chair (W3C I18N WG)
>
>     Internationalization is not a feature.
>
>     It is an architecture.
>
>     *From:*Sandro Hawke [mailto:sandro@w3.org]
>     *Sent:* Friday, June 24, 2016 12:46 PM
>     *To:* Phillips, Addison <addison@lab126.com>
>     <mailto:addison@lab126.com>; Richard Ishida, Staff Contact, i18n
>     WG <ishida@w3.org> <mailto:ishida@w3.org>
>     *Cc:* public-socialweb@w3.org <mailto:public-socialweb@w3.org>
>     *Subject:* Reviewing Social Web Specs
>
>     I'm writing on behalf of the Social Web WG.  Some of our specs are
>     now stable, and if we would value a review from your group at your
>     earliest convenience.  While our primary use cases are often
>     framed in terms of social media and blogging, the technologies may
>     be broadly applicable.
>
>     So far we have three specs in or near CR:
>
>         * *Webmention* lets you tell a website you're linking to it. 
>         This supports ad hoc federation of sites
>
>         https://www.w3.org/TR/webmention/
>
>         * *Activity Streams* (2.0) is a standard (and extensible) way
>         to share a stream of what people do online (eg, "liking",
>         posting a photo, etc)
>
>         https://www.w3.org/TR/activitystreams-core/
>         https://www.w3.org/TR/activitystreams-vocabulary/
>
>         * *Micropub* provides a standard Web API to create and control
>         posts on your own website
>
>         https://www.w3.org/TR/micropub/
>
>
>     Additionally:
>
>         * *Social Web Protocols*: provides an overview, including an
>         explanation for how the parts fit (and sometimes do not fit)
>         together. This document does not currently have any normative
>         content.
>
>         https://www.w3.org/TR/social-web-protocols/
>
>
>     There are other documents not yet ready for horizontal review. 
>     You'll see them linked from Social Web Protocols, and we'll send
>     another email when they're in or near CR.
>
>     Note that the group is producing multiple stacks which are not
>     entirely compatible, reflecting the fragmentation in this space.
>     Basically, we decided having multiple competing specs, while not
>     an ideal situation, would still be a step forward.
>
>     If you think your group will be doing a review, please reply-all
>     and let us know your timeframe.  We'd very much appreciate the
>     actual review comments being raised as issues on the repo for each
>     particular spec (linked in the title section), and then a
>     high-level email or summary issue stating when the review is complete.
>
>     Please feel free to share this call-for-review with anyone likely
>     to be interested.
>
>     Thank you!
>
>        -- Sandro Hawke, Staff Contact, W3C Social Web Working Group
>
Received on Saturday, 25 June 2016 00:24:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:02:12 UTC