Re: Request to move HTML5.1 to Candidate Recommendation (CR)

[Sangwhan Moon]

> On Jun 3, 2016, at 01:35, Chaals McCathie Nevile  
> wrote:
> 
> On Thu, 02 Jun 2016 18:14:38 +0200,  wrote:
> 
>> Can we please kindly stop the +1s spam? It greatly diminishes the value of 
>> this mailing list.
>> 
>> For the purpose of progressing a spec, the only thing that matters is 
>> objections.
> 
> Hi Marcos,
> 
> If there are no objections, then the +1's indeed don't matter. But if there 
> is one or more, then having some measure of the overall consensus of the 
> group is important.
> 
> It's why we've got the arrangement that except where progressing makes a 
> significant difference, we do it automatically and allow for objection as the 
> exception case. Moving to CR potentially binds members to patent commitments, 
> which matters to some members as well as to many people "out there in the 
> wild", and requires that we demonstrate agreement of the group.
> 
> So I'm sorry for the extra mail, but in this case I'm afraid it's part of 
> running the W3C process. If everything goes smoothly, you can expect this for 
> HTML twice more in the next year: once to move to Proposed Recommendation, 
> and once to move 5.2 to First Public Working Draft.

I believe Marcos is raising a valid concern here - while I'm not in full 
agreement that only objections
matter, most of the people get enough mail already and it does make it easy to 
get important feedback
lost in a chain of +1 mails. (and when it piles up, it's just something you zip 
through and mark as read,
now repeat time spent doing that multiplied by subscribers of this ML...)

Having a platform where the chairs/staff can get a quick overview of the 
consensus stats sounds a
like it could save time in the even anyone needs the consensus statistics. (As 
mentioned in a earlier
reply, WBS could work, even if it's not a great tool per se.)

Sangwhan

>>> On 3 Jun 2016, at 12:36 AM, Mona Rekhi  wrote:
>>> 
>>> +1
>>> 
>>> Mona Rekhi
>>> SSB BART Group
>>> 
>>> -Original Message-
>>> From: Léonie Watson [mailto:t...@tink.uk]
>>> Sent: Thursday, June 02, 2016 8:48 AM
>>> To: 'public-webapps WG' 
>>> Subject: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)
>>> 
>>> Hello WP,
>>> 
>>> This is a call for consensus to request that W3C publish the current HTML 
>>> Working Draft (WD) as a Candidate Recommendation (CR). It has been posted 
>>> to public-webapps@w3.org as the official email for this WG.
>>> 
>>> Please reply to this thread on public-webapps@w3.org  no later than end of 
>>> day on 10 June. Positive responses are preferred and encouraged, silence 
>>> will be considered as assent.
>>> 
>>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that 
>>> make it more reliable, more readable and understandable, and a better match 
>>> for reality. Substantial changes between HTML5 and HTML5.1 can be found in 
>>> the spec [2].
>>> 
>>> When a specification moves to CR it triggers a Call For Exclusions, per 
>>> section 4 of the W3C Patent Policy [3]. No substantive additions can be 
>>> made to a specification in CR without starting a new Call for Exclusions, 
>>> so we will put HTML5.1 into "feature freeze". It is possible to make 
>>> editorial updates as necessary, and features marked "At Risk" may be 
>>> removed if found not to be interoperable.
>>> 
>>> The following features are considered "at risk". If we cannot identify at 
>>> least two shipping implementations, they will be marked "at risk" in the CR 
>>> and may be removed from the Proposed Recommendation.
>>> 
>>> keygen element. [issue 43]
>>> label as a reassociatable element [issue 109] Fixing requestAnimationFrame 
>>> to 60Hz, not implementation-defined [issues 159/375/422] 
>>> registerContentHandler [Issue 233] inputmode attribute of the input element 
>>> [issue 269] autofill of form elements [issue 372] menu, menuitem and 
>>> context menus. [issue 373] dialog element [issue 427] Text tracks exposing 
>>> in-band metadata best practices [Issue 461] datetime and datatime-local 
>>> states of the input element [Issue 462]
>>> 
>>> Please share implementation details for any of these features on Github. To 
>>> mark other features "at risk", please identify them by 10th June (ideally 
>>> by filing an issue and providing a test case).
>>> 
>>> At the same time we move HTML5.1 into CR, we plan to continue updating the 
>>> Editor's Draft, and in the next few weeks we expect to post a Call for 
>>> Consensus to publish it as the First Public Working Draft of HTML5.2, so 
>>> improving HTML will continue without a pause. It also means that changes 
>>> that didn't make it into
>>> HTML5.1 will not have long to wait before being incorporated into the 
>>> specification.
>>> 
>>> Léonie on behalf of the WP chairs and team, and HTML editors.
>>> [1] https://www.w3.org/TR/html51/
>>> [2] https://www.w3.org/TR/html51/changes.html#changes
>>> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>>> 
>>> [issue 43] https://g

Re: [XHR]

[Sangwhan Moon]

> On Mar 17, 2016, at 3:12 AM, Jonas Sicking  wrote:
> 
>> On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr.  
>> wrote:
>> No, streams do not solve the problem of "how do you present a
>> partially-downloaded JSON object".  They handle chunked data *better*,
>> so they'll improve "text" response handling,
> 
> Also binary handling should be improved with streams.
> 
>> but there's still the
>> fundamental problem that an incomplete JSON or XML document can't, in
>> general, be reasonably parsed into a result.  Neither format is
>> designed for streaming.
> 
> Indeed.
> 
>> (This is annoying - it would be nice to have a streaming-friendly JSON
>> format.  There are some XML variants that are streaming-friendly, but
>> not "normal" XML.)
> 
> For XML there is SAX. However I don't think XML sees enough usage
> these days that it'd be worth adding native support for SAX to the
> platform. Better rely on libraries to handle that use case.
> 
> While JSON does see a lot of usage these days, I've not heard of much
> usage of streaming JSON. But maybe others have?
> 
> Something like SAX but for JSON would indeed be cool, but I'd rather
> see it done as libraries to demonstrate demand before we add it to the
> platform.

Something like SAX for JSON would be nice.

For an immediately available userland solution RFC7049 is an alternative to 
JSON which is slightly more streaming friendly.

Downside is that it's unreadable by humans, and a bit too low level for a fair 
amount of usecases. (Parsing is much simpler than existing binary object 
serialization formats, such as ASN1)

Sangwhan

[1] https://tools.ietf.org/html/rfc7049

Re: Art steps down - thank you for everything

[Sangwhan Moon]

> On Jan 29, 2016, at 00:45, Chaals McCathie Nevile  
> wrote:
> 
> Hi folks,
> 
> as you may have noticed, Art has resigned as a co-chair of the Web Platform 
> group. He began chairing the Web Application Formats group about a decade 
> ago, became the leading co-chair when it merged with Web APIs to become the 
> Web Apps working group, and was instrumental in making the transition from 
> Web Apps to the Web Platform Group. (He also chaired various other W3C groups 
> in that time).
> 
> I've been very privileged to work with Art on the webapps group for so many 
> years - as many of you know, without him it would have been a much poorer 
> group, and run much less smoothly. He did a great deal of work for the group 
> throughout his time as co-chair, efficiently, reliably, and quietly.
> 
> Now we are three co-chairs, we will work between us to fill Art's shoes. It 
> won't be easy.
> 
> Thanks Art for everything you've done for the group for so long.
> 
> Good luck, and I hope to see you around.

Likewise, Art - you will be missed. It was a true pleasure working with you 
over the years.

Sangwhan


signature.asc
Description: Message signed with OpenPGP using GPGMail