Re: do not deprecate synchronous XMLHttpRequest

[Glenn Adams]

Given implementations already support synchronous behavior, the only reason
to deprecate would be if continuing to support that behavior comes at a
significant burden to future versions of these implementations. I would
conjecture it is not, so I oppose deprecation on the principle that policy
should be determined by the user/author, not the standard.

Morality should not be legislated!


On Tue, Feb 10, 2015 at 7:47 AM, Ashley Gullen  wrote:

> I am on the side that synchronous AJAX should definitely be deprecated,
> except in web workers where sync stuff is OK.
>
> Especially on the modern web, there are two really good alternatives:
> - write your code in a web worker where synchronous calls don't hang the
> browser
> - write async code which doesn't hang the browser
>
> With modern tools like Promises and the new Fetch API, I can't think of
> any reason to write a synchronous AJAX request on the main thread, when an
> async one could have been written instead with probably little extra effort.
>
> Alas, existing codebases rely on it, so it cannot be removed easily. But I
> can't see why anyone would argue that it's a good design principle to make
> possibly seconds-long synchronous calls on the UI thread.
>
>
>
>
> On 9 February 2015 at 19:33, George Calvert 
> wrote:
>
>> I third Michaela and Gregg.
>>
>>
>>
>> It is the app and site developers' job to decide whether the user should
>> wait on the server — not the standard's and, 99.9% of the time, not the
>> browser's either.
>>
>>
>>
>> I agree a well-designed site avoids synchronous calls.  BUT — there still
>> are plenty of real-world cases where the best choice is having the user
>> wait: Like when subsequent options depend on the server's reply.  Or more
>> nuanced, app/content-specific cases where rewinding after an earlier
>> transaction fails is detrimental to the overall UX or simply impractical to
>> code.
>>
>>
>>
>> Let's focus our energies elsewhere — dispensing with browser warnings
>> that tell me what I already know and with deprecating features that are
>> well-entrenched and, on occasion, incredibly useful.
>>
>>
>>
>> Thanks,
>> George Calvert
>>
>
>

Re: Are web components *seriously* not namespaced?

[Glenn Adams]

On Wed, Feb 4, 2015 at 2:31 PM, Glen  wrote:

> I know I'm rather late to the party, but I've been doing a lot of reading
> lately about web components and related technologies, and the one thing
> that confounds me is the fact that web components appear not to have any
> "real" namespacing.
>

There is a serious antipathy towards XML in some quarters. So I believe the
vocabulary was designed for non-XML namespace aware parsers. Others can
verify my understanding (or not).


>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>
> Regards,
>
> Glen.
>
>

Re: CfC: publish Proposed Recommendation of Server-Sent Events; deadline November 28

[Glenn Adams]

+1

On Fri, Nov 21, 2014 at 7:02 AM, Arthur Barstow 
wrote:

> The latest interop data Zhiqiang generated for Server-sent Events [All]
> indicates 102/124 passes and [<2] isolates the 22 failures with less than
> two implementations including 9 failures which are due to Web IDL
> implementation bugs (thus, not counting the WebIDL failures the pass rate
> is 111/124 or ~90%).
>
> The non Web IDL failures are:
>
> 1. http://www.w3c-test.org/eventsource/dedicated-worker/
> eventsource-constructor-non-same-origin.htm
> 2. http://www.w3c-test.org/eventsource/shared-worker/
> eventsource-constructor-non-same-origin.htm
> 3. http://www.w3c-test.org/eventsource/format-field-retry-bogus.htm
>
> My take on these failures is:
>
> #1 and #2 test the UA's error handling of URLs that cannot be resolved
> (f.ex. unsupported URL scheme, URL doesn't exist). The failures appear to
> be relatively low priority implementation bugs (see [Bug119974]) that seem
> unlikely to occur in a tested deployment.
>
> #3 tests the UA's handling of invalid data value for the retry
> (constructor) parameter. This test actually now passes when I run it on FF
> beta 34.0 so it should be removed from [<2]. Regardless, the failure
> appears to be a relatively low priority implementation bug that seems
> unlikely to occur in a tested deployment.
>
> As such, this is Call for Consensus to publish SSE as a Proposed
> Recommendation. If you have any comments or concerns about this CfC, please
> reply to this e-mail by November 28 at the latest. Positive response is
> preferred and encouraged, and silence will be considered as agreement with
> the proposal.
>
> The [ED] has changed since the [CR] was published (see [Diff]) so this
> proposal assumes that if/when there is a resource commitment to include
> changes on the TR track, that will be done separately.
>
> -Thanks, AB
>
> [All] 
> [<2] 
> [Bug119974] 
>
> [CR] 
> [ED] 
> [Diff]  2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html%
> 3Frev%3D1.233%3Bcontent-type%3Dtext%252Fhtml&doc2=http%3A%
> 2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%
> 2Feventsource%2FOverview.html%3Frev%3D1.258%3Bcontent-type%3Dtext%252Fhtml>
>
>
>
>
>

Re: publishing new WD of URL spec

[Glenn Adams]

On Thu, Sep 11, 2014 at 2:20 PM, Robin Berjon  wrote:

> On 11/09/2014 00:14 , Glenn Adams wrote:
>
>> WHATWG specs are not legitimate for reference by W3C specs. Their IPR
>> status is indeterminate and they do not follow a consensus process.
>>
>
> This is blatant trolling as well as factually wrong in every single
> statement that it makes.
>

I would say something impolite and vulgar at this point. But you've already
pulled down this thread to the gutter Robin by resorting to name calling,
so I won't do that.


>
> I would invite all of you to not feed this thread as it can't possibly
> lead anywhere useful.


You mean, don't feed it like you are doing?

As a W3T member, I would think it your duty to stay out of the fray. Best
listen to your duty.


>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Re: publishing new WD of URL spec

[Glenn Adams]

On Thu, Sep 11, 2014 at 12:27 AM, James Robinson  wrote:

> On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams  wrote:
>
>> WHATWG specs are not legitimate for reference by W3C specs.
>>
>
> Do you have a citation to back up this claim?
>

If it isn't obvious, I am stating my opinion regarding the matter of
legitimacy. Just like Domenic is stating his opinion. My opinion is based
on 20 years of experience with the W3C and 40 years of experience with
standards bodies.

In contrast, my claim regarding IPR policy and lack of consensus is not an
opinion, but an uncontested fact. Or would you dispute this?


>
>
>> Their IPR status is indeterminate and they do not follow a consensus
>> process.
>>
>
> Do you have citations for where this is listed as part of the requirements
> for references in W3C specifications?
>

The current W3C normative references guidelines [1], only recently
published, are the only written policy of which I'm aware. This document
does not prohibit referencing a WHATWG document. Ultimately, only TBL (or
his delegate) will make a decision on such matters. But I trust they will
take input from their members into account.

Reading [1], one wonders how the WHATWG would fare on the question of
"Stability of the Referenced Document", including "Stability of the
Organization/Group". Since there is no organization per se, and since the
philosophy of the WHATWG is explicitly contrasted with the notion of
"stability", then there are serious questions to be asked about permitting
such a reference.

[1] http://www.w3.org/2013/09/normative-references


>
> I know these are your personal opinions but am not aware of anything that
> states this is W3C process.
>

I agree, but that doesn't mean that it is acceptable or even a good idea to
permit normative references to a WHATWG "work", i.e., a work of Hixie and
friends. Personally, I don't care how good the technical content of this
work is if its authors refuse to participate in accepted processes. Why,
for instance, is this work [URL] not being taken to the IETF? That is the
natural home for such work. From all appearance, the answer is that Hixie
et al don't like playing the normally accepted standards process game and
wish to sideline it for their own ends. While I admire Hixie and his group
of friends for their technical proclivity, I do not admire their refusal to
work within accepted practices.

There is good value in following the W3C IPR policies and participating in
a consensus process. So I object to efforts that would diminish or
destabilize the value proposition of the W3C, the IETF, and other accepted
organizations, for no other apparent purpose than to satisfy the whim and
impatience of a gang of Young Turks.

I think this is all I need to say on this subject, so I will avoid
continuing this thread. Take it as you will.



>
> - James
>

Re: publishing new WD of URL spec

[Glenn Adams]

WHATWG specs are not legitimate for reference by W3C specs. Their IPR
status is indeterminate and they do not follow a consensus process.

On Wed, Sep 10, 2014 at 11:58 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> This is a formal objection to the publication of this specification.
>
> My arguments against publishing this specification include that copying
> the spec from the WHATWG is an unnecessarily combative way of working with
> another standards body, especially with regard to the URL Standard wherein
> we/they have been trying hard to address the issues of IP coverage and
> stable references on the W3C's terms. I would rather see this talked
> through and agreement come to regarding how the W3C can work to reference
> WHATWG specs in the same way that they reference Ecma or IETF specs.
>
> On the technical side, I argue that previous efforts to copy WHATWG specs,
> even well-intentioned ones like the DOM, have led to out-of-date snapshots
> permeating the internet, and causing developer and implementer confusion.
> (See links in [1]; see also the contrast between one implementer's policies
> at [2] and another's at [3].) We can't even fall back to "never look at TR
> because it is always out of date; use ED instead!" because in the case of
> e.g. DOM "4", the ED is five months out of date.
>
> I acknowledge that Dan is going to great lengths to make sure that this
> copying is done "right", insofar as it can be. E.g., he is copying not
> plagiarizing; he is stating that he wants feedback to flow through the
> upstream version instead of diverging; and he says that he will add more
> clear signposting to the document to help direct implementers and
> developers to the upstream version. However, I think this plan is merely a
> band-aid on a larger problem, akin to feeding the W3C's spec-copying
> addiction with a nicotine patch instead of a full-on cancer stick. An
> improvement, but I'd really prefer we break the addiction entirely.
>
> There are a number of remedies that would address this formal objection.
> The most preferable would be for the W3C to work amicably with the WHATWG
> to figure out a way to treat them and their specs as legitimate, instead of
> constantly copying them. This could include e.g. issuing a call to the AC
> reps in the webapps working group to commit to patent protection via the
> WHATWG's patent mechanism [4]. In the category of "these proposals MAY be
> vague or incomplete" [5], I would like the W3C to consider seriously how to
> react to the world wherein standards best serve the web by being living,
> and find some way to get out of the outmoded and bug-encouraging mode of
> thinking that stands behind "stable references."
>
> An alternate way of addressing the formal objection would be outline a
> very clear process for avoiding the dangers that have cropped up in
> previous WHATWG copies. This would include, among other things: an
> automated system for ensuring that the latest version of the upstream spec
> is always copied to TR; a blacklisting of outdated snapshots from search
> engines via robots.txt; some way of dealing with the fact that webapps
> patent commitments will be made to an outdated snapshot, but that snapshot
> should not be given any prominence for implementers or authors visiting the
> W3C website; and a public acknowledgement that implementers should not look
> at any outdated snapshots such as CR (so, the normal "call for
> implementations" would have to be modified, so we don't get ridiculous
> situations like HTML 5.0 is currently undergoing where you call for
> implementations of a spec that is multiple years behind what
> implementations actually need to implement for interoperability).
>
> [1]: http://wiki.whatwg.org/wiki/TR_strikes_again
> [2]: https://github.com/mozilla/servo/wiki/Relevant-spec-links
> [3]: http://status.modern.ie/
> [4]: http://blog.whatwg.org/make-patent-commitments
> [5]: http://www.w3.org/2014/Process-20140801/#FormalObjection
>
>
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: Wednesday, September 10, 2014 18:40
> To: public-webapps; www-...@w3.org
> Subject: PSA: publishing new WD of URL spec
>
> [ Sorry for the cross-posting but this is about a joint WD publication
> between WebApps and TAG. ]
>
> This is heads-up (aka PublicServiceAnnoucement) about the intent to
> publish a new WD of the URL spec (on or around Sept 16) using this ED as
> the basis:
>
>
>
> As previously agree, and codified in WebApps' current [Charter], the WD
> will be published jointly by WebApps and the TAG.
>
> I realize some people do not support W3C publishing the URL spec, so as
> reminder - as defined in WebApps' off-topic discussion policy
> ([OffTopic]) - if anyone has any _process-type_ comments, concerns, etc.
> about this publication - please send that feedback to the public-w3process
> list [w3process]. Please do _not_ send such feedback t

Re: First Draft of W3C version of URL Spec

[Glenn Adams]

On Thu, Aug 28, 2014 at 10:04 AM, Ian Hickson  wrote:

> On Wed, 27 Aug 2014, Daniel Appelquist wrote:
> >
> > As you might know, the new charter for webapps includes a new version
> > of the URL spec. I am acting as editor of this spec.
>
> What's the purpose of the W3C republishing this spec?
>

quite obviously, to have a reference to a stable document that follows the
W3C REC process, while WhatWG documents satisfy neither condition



>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

Re: First Draft of W3C version of URL Spec

[Glenn Adams]

On Wed, Aug 27, 2014 at 2:50 PM, Daniel Appelquist 
wrote:

> Hello URL fans -
>
> As you might know, the new charter for webapps[1] includes a new version
> of the URL spec. I am acting as editor of this spec. With some help from
> Robin and PLH I've produced a first draft[2] which imports the latest work
> by Anne on the upstream WHATWG URL spec[3] with a few minimal editorial
> changes.   Also note that the document is licensed as CC-BY. The intention
> is to keep this version in sync with the WHATWG version of the URL spec.
> This means that ideally any changes should be fed back through the WHATWG
> bug tracker[4]. The intention is to follow the model laid down by the DOM
> spec.[5]
>
> It’s my further intention to ensure confusion is minimized by clearly
> sign-posting in the w3c version that the WHATWG version is the living spec.
>

Make sure this is informative text. I don't know if the term "living
spec[ification]" has any formal meaning in the W3C. [Correct me if I missed
the memo that defines it.]


>
> This version updates and supersedes the previous W3C version published in
> May 2012[6] and later updated in November 2012[7].
>
> The goal is to move ahead fairly aggressively with the publication
> time-line for this spec.
>
> Please feed back any comments here.
>
> Thanks,
> Dan Appelquist
>
> 1. http://www.w3.org/2014/06/webapps-charter.html
> 2. http://w3ctag.github.io/url/
> 3. http://url.spec.whatwg.org
> 4.
> https://www.w3.org/Bugs/Public/buglist.cgi?component=URL&list_id=42864&product=WHATWG&resolution=---
> 5. http://www.w3.org/TR/dom/
> 6. http://www.w3.org/TR/url/
> 7. https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
>

Re: WebIDL Spec Status

[Glenn Adams]

On Fri, Jun 27, 2014 at 10:29 AM, Ian Hickson  wrote:

> On Fri, 27 Jun 2014, Glenn Adams wrote:
> > >
> > > For pointless certification purposes, you can use any random revision
> > > of the spec -- just say what the revision number is and use that (and
> > > honestly, who cares how well you implement that version -- it's not
> > > like the testing process is going to be thorough). Don't ship that,
> > > though. Whatever you ship should be regularly kept up to date with
> > > changes to the spec as they occur. (It's not an option to not be able
> > > to ship fixes, since otherwise you'd be unable to fix security
> > > vulnerabilities either, which is obviously a non-starter.) What you
> > > ship, and subsequent revisions thereto, is what you should be spending
> > > any serious amount of time testing. And for that, you shouldn't use a
> > > snapshot, you should use the latest revision of the spec.
> > >
> > > For the pointless certification, just as for the patent coverage, we
> > > should publish whatever revision we have and just stamp it as a REC.
> > > It doesn't matter what bugs it has. We know it'll have bugs -- the day
> > > after it's published, maybe even earlier, we'll find new bugs that
> > > will need fixing. It doesn't really matter, since it's not for use by
> > > implementors, just by lawyers and pointless certification teams.
> >
> > I would respond, but it would be ... pointless.
>
> I'm guessing you misinterpreted what I said, specifically, that you
> interpreted the "pointless" in "pointless certification" as an insult of
> some sort. To clarify, I did not mean it that way; I meant it literally,
> as in, specifically the kinds of certifications that you may be required
> to pursue for political or bureaucratic reasons but which have no
> practical purpose, as opposed to the kind of certification that serves an
> important purpose, like certifying that some software that's going to run
> a rocket passes all its tests.
>

No, I did not take it as an insult. I have too thick a skin to be insulted.
In any case, most insults thrown my way are probably true. :)

My use of "pointless" was intended to mean that it is pointless to argue
with you about whether certification required by "political or bureaucratic
reasons" (by which I understand you to include legal reasons as well) is or
is not "pointless" to use your phrase. Clearly I don't agree with your
position.


>
> Certifying that software passes tests for an obsolete version of a
> standard, when the standard's purpose is interoperability and achieving
> that interoperability requires converging on a target that we're only
> slowly reaching over many years, is at best pointless, and at worst
> harmful, which is why I stand by the advice above.
>

We have different understandings of the meaning of "interoperability". My
interpretation of your definition of interoperability is that it is a
ghost: in the sense that it has no fixed point of reference, i.e., no fixed
set of specifications against which it (interoperability) can be certified.

Clearly we operate in different business regimes.


>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: WebIDL Spec Status

[Glenn Adams]

On Thu, Jun 26, 2014 at 10:18 AM, Ian Hickson  wrote:

> On Wed, 25 Jun 2014, Glenn Adams wrote:
> > On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson  wrote:
> > >
> > > Compraing implementations to anything but the very latest draft is not
> > > only a waste of time, it's actively harmful to interoperability. At no
> > > point should any implementor even remotely consider making a change
> > > from implementing what is currently specified to what was previously
> > > specified, that would literally be going backwards.
> >
> > That sounds reasonable, but its not always true (an exception to every
> > rule, eh). For example, in order to ship a device that must satisfy
> > compliance testing to be certified, e.g., to be granted a branding
> > label, to satisfy a government mandate, etc., it may be necessary to
> > implement and ship support for an earlier version.
>
> For pointless certification purposes, you can use any random revision of
> the spec -- just say what the revision number is and use that (and
> honestly, who cares how well you implement that version -- it's not like
> the testing process is going to be thorough). Don't ship that, though.
> Whatever you ship should be regularly kept up to date with changes to the
> spec as they occur. (It's not an option to not be able to ship fixes,
> since otherwise you'd be unable to fix security vulnerabilities either,
> which is obviously a non-starter.) What you ship, and subsequent revisions
> thereto, is what you should be spending any serious amount of time
> testing. And for that, you shouldn't use a snapshot, you should use the
> latest revision of the spec.
>
> For the pointless certification, just as for the patent coverage, we
> should publish whatever revision we have and just stamp it as a REC. It
> doesn't matter what bugs it has. We know it'll have bugs -- the day after
> it's published, maybe even earlier, we'll find new bugs that will need
> fixing. It doesn't really matter, since it's not for use by implementors,
> just by lawyers and pointless certification teams.
>

I would respond, but it would be ... pointless.


>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: WebIDL Spec Status

[Glenn Adams]

On Thu, Jun 26, 2014 at 4:52 AM, Arthur Barstow 
wrote:

> On 6/25/14 11:58 AM, Glenn Adams wrote:
>
>> In the case of WebIDL, my personal preference would be to not spend
>> precious effort on WebIDL 1 CR, but instead to:
>>
>> (1) publish WebIDL 1 CR as a WG Note without attempting to resolve
>> outstanding issues, other than by clearly annotating the existence of those
>> issues in the Note;
>> (2) focus on moving WebIDL 2E (2nd edition) to FPWD and thence to LC, etc.
>>
>> If this process is followed, then it also may be useful to relabel these
>> two works a bit, e.g., by calling what is now WebIDL CR something like
>> "WebIDL Legacy" in a WG Note, and then using the generic name WebIDL for
>> what is now called WebIDL 2E. Just an idea to consider.
>>
>
> Well, I admit I like this proposal, quite a lot actually, however, I don't
> know if it will satisfy the relevant process requirements (f.ex.
> [NormRef]). (Perhaps I should move this proposal to the public-w3process
> list ...)
>
> Phillippe, Yves, Cindy - what are your thoughts on Glenn's proposal for v1?
>
> Glenn - would your v1 WG Note proposal satisfy all of the WebIDL reference
> cases that concern you (I'm wondering in particular about specs from other
> SSOs that reference WebIDL)?
>

The reference cases I'm working with (primarily DLNA specs) dereference
WebIDL via the HTML5 references list, which in turn, refers to WebIDL 2E.
So at this point, I have no issue with the existing CR being moved to a WG
Note.

Given the limited editorial resources, I prefer effort going into
progressing 2E.


>
> All - feedback on Glenn's proposal is certainly welcome.
>
> -Thanks, AB
>
> [NormRef] <http://www.w3.org/2013/09/normative-references>
>
>
>

Re: WebIDL Spec Status

[Glenn Adams]

On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson  wrote:

> On Tue, 24 Jun 2014, Boris Zbarsky wrote:
> > On 6/24/14, 1:05 PM, Glenn Adams wrote:
> > > Such device certification regimes cannot work unless the referenced
> > > specifications are locked down and clearly implementable.
> >
> > I see.
> >
> > So this is not about actual spec implementations or spec authors but
> > effectively about a QA cycle that compares the implementations to the
> > specs, and which needs to know which spec to compare the implementations
> > to.
>
> Compraing implementations to anything but the very latest draft is not
> only a waste of time, it's actively harmful to interoperability. At no
> point should any implementor even remotely consider making a change from
> implementing what is currently specified to what was previously specified,
> that would literally be going backwards.
>

That sounds reasonable, but its not always true (an exception to every
rule, eh). For example, in order to ship a device that must satisfy
compliance testing to be certified, e.g., to be granted a branding label,
to satisfy a government mandate, etc., it may be necessary to implement and
ship support for an earlier version.

In the case of WebIDL, my personal preference would be to not spend
precious effort on WebIDL 1 CR, but instead to:

(1) publish WebIDL 1 CR as a WG Note without attempting to resolve
outstanding issues, other than by clearly annotating the existence of those
issues in the Note;
(2) focus on moving WebIDL 2E (2nd edition) to FPWD and thence to LC, etc.

If this process is followed, then it also may be useful to relabel these
two works a bit, e.g., by calling what is now WebIDL CR something like
"WebIDL Legacy" in a WG Note, and then using the generic name WebIDL for
what is now called WebIDL 2E. Just an idea to consider.

Re: WebIDL Spec Status

[Glenn Adams]

On Tue, Jun 24, 2014 at 3:28 PM, Cameron McCormack  wrote:

> On 24/06/14 20:50, Arthur Barstow wrote:
>
>> On 6/23/14 4:04 PM, Glenn Adams wrote:
>>
>>> What is the plan, i.e., schedule timeline, for moving WebIDL to REC?
>>> We have now a two year old CR that appears to be stuck and a 2nd
>>> Edition that I'm not sure has made it to FPWD.
>>>
>>
>> Hi Glenn, All,
>>
>> I don't have any new info re v1 beyond what Boris said a few weeks ago
>> in this thread:
>> <http://lists.w3.org/Archives/Public/public-script-coord/
>> 2014AprJun/0162.html>.
>>
>>
>> Cameron, Boris - please reply to Glenn's question.
>>
>
> I've put Web IDL work on my list of Q3 goals, so I will resume work on it
> next month.
>
> I still think that before publishing another draft on TR/ that we should
> resolve the open issues that apply to v1.  Boris and I will be dividing up
> the open issues to split the work.
>

Sounds good.

Re: WebIDL Spec Status

[Glenn Adams]

On Tue, Jun 24, 2014 at 12:36 PM, Marcos  wrote:

>
>
> On June 24, 2014 at 2:33:41 PM, Glenn Adams (gl...@skynav.com) wrote:
> > > They are. By having me test IDL features, by having me report
> > them to Cameron, by having me participate in this WG. Are you asking
> > if they can supply an editor? That would best be handled by having
> > the chairs issue a call for volunteers for co-editor on WebIDL.
>
> Anyone can edit the spec. It's just a github repo. Send a PR. There is no
> need for a special call from the Chairs as an excuse to do work.
>

I realize you think that zero process is the best process, but I don't
agree. Becoming a co-editor should be a public commitment and not simply
random PRs. The chairs are well advised to call for volunteers if that is
needed.


>
>
> --
> Marcos Caceres
>
>
>

Re: WebIDL Spec Status

[Glenn Adams]

On Tue, Jun 24, 2014 at 11:57 AM, Boris Zbarsky  wrote:

> On 6/24/14, 1:46 PM, Glenn Adams wrote:
>
>> The primary goal of the W3C is to produce Technical Reports that reach a
>> stable level of maturity.
>>
>
> The Technical Reports are not an end in themselves.  They're a means to an
> end.  This is why we don't produce Technical Reports that just say "do
> whatever" if we can avoid it, because that would fail to fulfill our
> _actual_ goals (which might differ for different W3C members of course; for
> some of them maybe "do whatever" is good enough for their purposes).
>
> You're correct that sometimes the production of the Technical Report is
> viewed as an end in itself in an attempt to bridge the different member's
> actual goals.  Sometimes this works ok, and sometimes the result is a TR
> that is useless to some subset of members.
>
> I happen to be affiliated with a member for whom most TRs (possibly all of
> them) as practiced by the W3C tend to be somewhat useless compared to the
> process of putting together the TR, so I have certain biases in that regard.
>
>
>  If a WG fails to move a technical report to REC then it has failed its
>> chartered purpose (as far as that report is concerned).
>>
>
> Yes, agreed, as the W3C process is set up right now.  It's a bug, not a
> feature.  ;)
>
>
>  In my capacity in this WG, I represent a Full Member who pays for
>> membership in order to see technical work reach completion.
>>
>
> Is this Member willing to devote resources to getting there?
>

They are. By having me test IDL features, by having me report them to
Cameron, by having me participate in this WG. Are you asking if they can
supply an editor? That would best be handled by having the chairs issue a
call for volunteers for co-editor on WebIDL.


>
> Again, I'm not saying we shouldn't have a REC of Web IDL.  I'm saying that
> currently there's a perverse incentives problem: the only people who have
> stepped up to edit the spec are the ones who are affiliated with a Member
> which can'e make much use of a Web IDL REC in its current state all that
> much.  Which means that they end up, consciously or not, not prioritizing
> reaching REC on Web IDL v1, say, particularly highly.
>
>
>  In the current situation, I think the best course would be for the chair
>> and team members of this group to attempt to work with the editor to
>> define a reasonable schedule for moving it forward to REC, and, if
>> necessary call for volunteer co-editors if the current editor is unable
>> to invest sufficient time to see through that process.
>>
>
> Yep, we agree.
>
> -Boris
>

Re: WebIDL Spec Status

[Glenn Adams]

On Tue, Jun 24, 2014 at 11:08 AM, Boris Zbarsky  wrote:

> On 6/24/14, 1:05 PM, Glenn Adams wrote:
>
>> Such device certification regimes cannot work unless the referenced
>> specifications are locked down and clearly implementable.
>>
>
> I see.
>
> So this is not about actual spec implementations or spec authors but
> effectively about a QA cycle that compares the implementations to the
> specs, and which needs to know which spec to compare the implementations to.
>

Not at all. This is not about one or even a group of organizations or about
QA. It is about fulfilling the process goals of the W3C and the WebApps WG.

The primary goal of the W3C is to produce Technical Reports that reach a
stable level of maturity. The charter of each WG includes the creating of
technical reports at the REC maturity level, i.e., undergo the "REC track
process".

If a WG fails to move a technical report to REC then it has failed its
chartered purpose (as far as that report is concerned). Alternatively, it
could formally decide to abandon the work by moving it to a WG Note, which
implies it won't be further progressed to REC.

The W3C has customers other than browser vendors. It portrays itself as a
standards organization (at least informally) and talks about its work
products being standards (at least informally). Standards organizations
must move their work to some status that is recognized as complete,
otherwise they will become a joke in the larger community of SDOs and
customers.

In my capacity in this WG, I represent a Full Member who pays for
membership in order to see technical work reach completion. An ED or a CR
does not represent completion. They are willing to help wherever possible,
and devote considerable resources to the W3C at large. If at the end of the
day I have to tell them that key technical work, such as WebIDL, will never
reach REC, and that means that most key specifications (HTML5, DOM4) are
technically incomplete or at least untrustworthy (as concrete, well-defined
technical works), then it will have a negative impact on their use of those
specs as well as a negative impact on future investment in the W3C process.

In the current situation, I think the best course would be for the chair
and team members of this group to attempt to work with the editor to define
a reasonable schedule for moving it forward to REC, and, if necessary call
for volunteer co-editors if the current editor is unable to invest
sufficient time to see through that process. [I would note that Cameron has
done and is doing an outstanding job, but appears to be negatively impacted
by constant requests for new IDL features by ongoing spec writers.]

The bottom line is this about fulfilling the WhatWG charter and the W3C
process goals.




>
> In an ideal alignment of incentives, the organizations that need this sort
> of snapshot would step up to produce it, but I'm not sure how likely that
> is to happen in practice...
>
> -Boris
>

Re: WebIDL Spec Status

[Glenn Adams]

On Tue, Jun 24, 2014 at 7:14 AM, Boris Zbarsky  wrote:

> On 6/24/14, 6:56 AM, Charles McCathie Nevile wrote:
>
>> While nobody is offering an editor who can get the work
>> done, this argument is in any case academic (unless the editor's
>> availability is predicated on the outcome, in which case it would be mere
>> political machinations).
>>
>
> I strongly disagree with that characterization.
>
> The fact is, for browser vendors a stable v1 Web IDL snapshot as we have
> right now is not very useful, since that's not what they need to implement
> in practice: there are too many APIs currently being specified that cannot
> be expressed in that snapshot.  So it's really hard to justify devoting
> resources to such a snapshot.
>
> On the other hand, making Web IDL reflect ongoing specification reality is
> something that's really useful to browser vendors, so it might be easier to
> convince them to spend time on that.  No political machinations involved.
>
> A more recent snapshot might be more useful, but is still likely to end up
> not being an actual implementation target because there are still too many
> changes happening in terms of ES integration and the like.
>
> I don't have a good solution to this problem, unfortunately.  :(
>
> On the other hand, the only audience I see for a snapshot are
> specification writers who don't want/need the newer things we're adding to
> Web IDL.  Are there other audiences?  Are there actually such specification
> writers?  The recent set of changes to Web IDL have all been driven by
> specification needs.


There are organizations attempting to create device certification regimes
based on specifications that normatively reference HTML5, DOM4, XHR2,
Canvas2D, WebGL, etc, and many other W3C API specs all of which have a
normative dependency on the WebIDL in the sense that they must implement
IDL features in ECMAScript according to the ECMAScript binding semantics in
WebIDL, which, in turn become dependencies for testing.

Such device certification regimes cannot work unless the referenced
specifications are locked down and clearly implementable. Having a WebIDL
that is always in a state of flux makes such work well nigh impossible or
at best extremely difficult and untrustworthy.





>
>
> -Boris
>
>

Re: WebIDL Spec Status

[Glenn Adams]

On Mon, Jun 23, 2014 at 3:05 PM, Marcos  wrote:

>
>
> On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote:
> > What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We
> > have now a two year old CR that appears to be stuck and a 2nd Edition
> that
> > I'm not sure has made it to FPWD.
> >
> > Given the high degree of dependency from other specs and implementations
> on
> > this work, we really need to find a way to wrap up this work or at least
> > publish something reasonably stable.
>
>
> IMO, we should just concede that this document needs to be a Living
> Standard (tm).


I don't mind there being a "living standard" form of the document. But that
is not sufficient. There must be some final REC version of some
edition/snapshot of this work that provides a non-movable mark for
real-world compliance testing and device certification.


> Trying to move this through the W3C process is clearly not working.


There is no reason it can't or shouldn't.


> Even if we were able to take the V1 bits to Rec (a lot of which is now
> obsolete), the V2 stuff is already widely supported and heavily relied on
> by browser vendors. IMO, it's a waste of everyone's time to try to maintain
> multiple versions.
>

I agree that the V1 CR should be abandoned or replaced with a completed
snapshot of V2. Though it would be useful to ask a wider community about
the value of moving some flavor of V1 to REC.


>
> --
> Marcos Caceres
>
>
>

WebIDL Spec Status

[Glenn Adams]

What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We
have now a two year old CR that appears to be stuck and a 2nd Edition that
I'm not sure has made it to FPWD.

Given the high degree of dependency from other specs and implementations on
this work, we really need to find a way to wrap up this work or at least
publish something reasonably stable.

Regards,
Glenn

Re: [webappsec + webapps] CORS to PR plans

[Glenn Adams]

On Wed, Aug 7, 2013 at 8:54 AM, Glenn Adams  wrote:

>
> On Mon, Aug 5, 2013 at 5:48 PM, Brad Hill  wrote:
>
>> I'd like to issue this as a formal Call for Consensus at this point.  If
>> you have any objections to CORS advancing to Proposed Recommendation,
>> please reply to public-webapp...@w3.org.  Affirmative response are also
>> encouraged, and silence will be taken as assent.
>>
>
>
>>
>> The proposed draft is available at:
>>
>> http://webappsec-test.info/~bhill2/pub/CORS/index.html
>>
>> This CfC will end and be ratified by the WebAppSec WG on Tuesday, August
>> 13, 2013.
>>
>> Thank you,
>>
>> Brad Hill
>>
>>
>> On Tue, Jul 16, 2013 at 12:47 PM, Brad Hill  wrote:
>>
>>> WebAppSec and WebApps WGs,
>>>
>>>  CORS advanced to Candidate Recommendation this January, and I believe
>>> it is time we consider advancing it to Proposed Recommendation.  In the
>>> absence of an editor, I have been collecting bug reports sent to the
>>> public-webappsec list, and now have a proposed draft incorporating these
>>> fixes I would like to run by both WGs.
>>>
>>> The proposed draft can be found at:
>>>
>>> http://webappsec-test.info/~bhill2/pub/CORS/index.html
>>>
>>> A diff-marked version is available at:
>>>
>>>
>>> http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html
>>>
>>> (pardon some spurious diffs indicated in pre-formatted text that has not
>>> actually changed)
>>>
>>> A list of changes is as follows:
>>>
>>> 1. Changed "Fetch" references.  The CR document referenced the WHATWG
>>> Fetch spec in a number of places.  This was problematic due to the maturity
>>> / stability requirements of the W3C for document advancement, and I feel
>>> also inappropriate, as the current Fetch spec positions itself as a
>>> successor to CORS, not a reference in terms of which CORS is defined.  The
>>> proposal is to substitute these references for the "Fetching Resources"
>>> section of the HTML5 spec at:
>>>
>>> http://www.w3.org/TR/html5/infrastructure.html#fetching-resources
>>>
>>> I do not believe this produces substantive changes in the reading of
>>> CORS>
>>>
>>> 2. In the "Terminology" section, added a comma after "Concept" in
>>> response to:
>>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html
>>>
>>> 3. Per discussion to clarify the interaction of HTTP Authorization
>>> headers with the user credentials flag,
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 and
>>> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0366.html,
>>> I have inserted the following clarification:
>>>
>>> "user credentials for the purposes of this specification means cookies,
>>> HTTP authentication, and client-side SSL certificates
>>>that would be sent based on the user agent's
>>> previous interactions with the origin. 
>>>
>>> 4. In the defintion of the Access-Control-Allow-Methods header, in
>>> response to
>>> http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0046.html, 
>>> clarified that "The Allow header is not relevant for the purposes of the
>>> CORS protocol.
>>>
>>> 5.
>>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.htmland
>>>
>>> http://lists.w3.org/Archives/Public/public-webappsec/2013Mar/0096.htmlpoint 
>>> out
>>>  that header and method are not defined correctly in the response
>>> headers for preflight requests.
>>>  It appears that the intent was to respond with the list provided as
>>> part of the preflight request,
>>>  rather than the potentially unbounded list the resource may
>>> actually support
>>>
>>>The following clarifications were made:
>>>
>>>   (for methods) "Since the list of methods can be unbounded, simply
>>> returning the method indicated by
>>> Access-Control-Request-Method (if supported) can be enough.
>>>
>>>   (for headers) "Since the list of headers can be unbounded, simply
>>> returning the headers from
>>> Access-Control-Allow-Headers (if supported) can be enough.
>>>
>>
&

Re: Updated idlharness.js

[Glenn Adams]

On Thu, Jan 24, 2013 at 8:19 AM, Robin Berjon  wrote:

> On 23/01/2013 19:11 , Glenn Adams wrote:
>
>> were you able to incorporate the improvements I suggested at [1]?
>>
>> [1] 
>> https://github.com/darobin/**webidl.js/pull/16<https://github.com/darobin/webidl.js/pull/16>
>>
>
> Well, it's an entirely different code base, so certainly not as is. But at
> least some of what you describe in there should be supported. (In
> webidl2.js that is, not idlharness.js).


Sure. If the following are supported, then I'll be able to switch to this
new implementation:

   - ability to provide string valued extended attributes, e.g.,
   Documentation
   - ability to provide extended attributes that apply to other extended
   attributes, e.g.,

[Documentation="Foo ..."
  [Documentation="Constructor of Foo ..."]
  Constructor(DOMString foo)
]
interface Foo { }

Re: Updated idlharness.js

[Glenn Adams]

were you able to incorporate the improvements I suggested at [1]?

[1] https://github.com/darobin/webidl.js/pull/16

On Wed, Jan 23, 2013 at 9:31 AM, Robin Berjon  wrote:

> Hi all,
>
> as you know, one of the tools that we have for testing is idlharness. What
> it does is basically that it processes some WebIDL, is given some objects
> that correspond to it, and it tests them for a bunch of pesky aspects that
> one should not have to test by hand.
>
> One of the issues with idlharness is that it has long been based on
> webidl.js which was a quick and dirty WebIDL parser that I'd written
> because I needed it for a project that petered out. This meant that it
> increasingly didn't support newer constructs in WebIDL that are now in
> common use.
>
> In order to remedy this, I have now made an updated version of idlharness
> that uses webidl2.js, a much better parser that is believed to be rather
> complete and correct (at least, it tests well against the WebIDL tests that
> we have). The newer webidl2.js does bring as much backwards compatibility
> with webidl.js as possible, but in a number of cases that simply wasn't
> possible (because WebIDL has changed too much to fit well into the previous
> model, and also because mistakes were made with it).
>
> You can find the updated version of idlharness in this branch:
>
> 
> https://github.com/w3c/**testharness.js/tree/webidl2
>
> The reason I'm prodding you is that idlharness, ironically enough, does
> not have a test suite. Because of that, I can't be entirely comfortable
> that the updated version works well and doesn't break existing usage. I've
> tested it with some existing content (e.g. http://berjon.com/tmp/geotest/*
> *) but that's no guarantee.
>
> So if you've been using idlharness, I'd like to hear about it. If you
> could give the new version a ride to see if you get the same results it'd
> be lovely. Once I hear back from enough people that it works (or if no one
> says anything) I'll merge the changes to the master branch.
>
> Thanks!
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

I need to clarify one point: I don't mind W3C docs making informative
references to WHATWG docs. For example, I wouldn't mind a W3C doc making a
normative reference to a snapshot of a WHATWG doc that has been republished
in the W3C while making an informative reference to its "living"
counterpart in the WHATWG.

On Sat, Dec 1, 2012 at 7:40 PM, Glenn Adams  wrote:

>
> On Sat, Dec 1, 2012 at 7:07 PM, James Robinson  wrote:
>
>>
>> On Sat, Dec 1, 2012 at 5:54 PM, Glenn Adams  wrote:
>>
>>>
>>> On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr. wrote:
>>>
>>>> On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams  wrote:
>>>> > On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger  wrote:
>>>> >> I object to this publication because of this change:
>>>> >>
>>>> >> http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
>>>> >>
>>>> >> pushed with a misleading commit message.
>>>> >
>>>> > since you don't say what is misleading, and since commit messages are
>>>> > irrelevant for W3C process, this  objection is immaterial
>>>>
>>>> Ms2ger objected to the change, not the commit message, so your
>>>> objection to the objection is misplaced.
>>>>
>>>> However, the commit message isn't long, so it's not difficult to
>>>> puzzle out what ey might be referring to.  In this case, it's the
>>>> implication that changing a bunch of normative references from WHATWG
>>>> specs to W3C copies of the specs is somehow necessary "according to
>>>> pubrules".
>>>>
>>>
>>> Then whomever ms2ger is should say so. In any case, there  is no reason
>>> to reference a WHATWG document if there is a W3C counterpart.
>>>
>>
>> Sure there is if the W3C version is stale, as is the case here.  That
>> commit replaced a link to http://xhr.spec.whatwg.org/, last updated
>> roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/which 
>> is dated January 17th and is missing an entire section (section 6).
>>  It also replaced a link to http://fetch.spec.whatwg.org/# with
>> http://www.w3.org/TR/cors/# which is similarly out of date by the better
>> part of a year and lacking handling for some HTTP status codes.  Every
>> single reference updated in this commit changed the document to point to an
>> out-of-date and less valuable resource.
>>
>> It seems that you, like the author of the commit message, mistakenly
>> think it's a goal to replace all links to point to W3C resources even when
>> they are strictly worse.  That's not in the W3C pub rules or a good idea.
>>
>
> I didn't suggest this was demanded by pubrules, and indeed, I pointed out
> in a prior message that the pub rules do not dictate what documents or
> referenced.
>
> My position w.r.t WHATWG documents is that they should never be referenced
> by a W3C document unless there is no other option. Why do I say this?
> Because WHATWG documents are never final, at least according their
> principals. The W3C should not reference a document that is by definition
> never going to reach a final state, at least that is my opinion. Further,
> the W3C should not reference a document for which the IPR status is not
> sufficiently well defined, again this is my opinion. You or others may
> disagree.
>
> In the cases in point, someone needs to determine if the referenced
> documents will continue to move forward in the W3C, and if so, then they
> need to be updated according to the W3C Process rules.
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0501.html
>

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Sat, Dec 1, 2012 at 7:07 PM, James Robinson  wrote:

>
> On Sat, Dec 1, 2012 at 5:54 PM, Glenn Adams  wrote:
>
>>
>> On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr. wrote:
>>
>>> On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams  wrote:
>>> > On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger  wrote:
>>> >> I object to this publication because of this change:
>>> >>
>>> >> http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
>>> >>
>>> >> pushed with a misleading commit message.
>>> >
>>> > since you don't say what is misleading, and since commit messages are
>>> > irrelevant for W3C process, this  objection is immaterial
>>>
>>> Ms2ger objected to the change, not the commit message, so your
>>> objection to the objection is misplaced.
>>>
>>> However, the commit message isn't long, so it's not difficult to
>>> puzzle out what ey might be referring to.  In this case, it's the
>>> implication that changing a bunch of normative references from WHATWG
>>> specs to W3C copies of the specs is somehow necessary "according to
>>> pubrules".
>>>
>>
>> Then whomever ms2ger is should say so. In any case, there  is no reason
>> to reference a WHATWG document if there is a W3C counterpart.
>>
>
> Sure there is if the W3C version is stale, as is the case here.  That
> commit replaced a link to http://xhr.spec.whatwg.org/, last updated
> roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/which 
> is dated January 17th and is missing an entire section (section 6).
>  It also replaced a link to http://fetch.spec.whatwg.org/# with
> http://www.w3.org/TR/cors/# which is similarly out of date by the better
> part of a year and lacking handling for some HTTP status codes.  Every
> single reference updated in this commit changed the document to point to an
> out-of-date and less valuable resource.
>
> It seems that you, like the author of the commit message, mistakenly think
> it's a goal to replace all links to point to W3C resources even when they
> are strictly worse.  That's not in the W3C pub rules or a good idea.
>

I didn't suggest this was demanded by pubrules, and indeed, I pointed out
in a prior message that the pub rules do not dictate what documents or
referenced.

My position w.r.t WHATWG documents is that they should never be referenced
by a W3C document unless there is no other option. Why do I say this?
Because WHATWG documents are never final, at least according their
principals. The W3C should not reference a document that is by definition
never going to reach a final state, at least that is my opinion. Further,
the W3C should not reference a document for which the IPR status is not
sufficiently well defined, again this is my opinion. You or others may
disagree.

In the cases in point, someone needs to determine if the referenced
documents will continue to move forward in the W3C, and if so, then they
need to be updated according to the W3C Process rules.

[1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0501.html

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr.  wrote:

> On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams  wrote:
> > On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger  wrote:
> >> I object to this publication because of this change:
> >>
> >> http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
> >>
> >> pushed with a misleading commit message.
> >
> > since you don't say what is misleading, and since commit messages are
> > irrelevant for W3C process, this  objection is immaterial
>
> Ms2ger objected to the change, not the commit message, so your
> objection to the objection is misplaced.
>
> However, the commit message isn't long, so it's not difficult to
> puzzle out what ey might be referring to.  In this case, it's the
> implication that changing a bunch of normative references from WHATWG
> specs to W3C copies of the specs is somehow necessary "according to
> pubrules".
>

Then whomever ms2ger is should say so. In any case, there  is no reason to
reference a WHATWG document if there is a W3C counterpart.

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger  wrote:

> On 11/27/2012 02:16 PM, Arthur Barstow wrote:
>
>> On 11/27/12 12:21 AM, ext Jungkee Song wrote:
>>
>>> From: Arthur Barstow [mailto:art.bars...@nokia.com]
 Sent: Tuesday, November 27, 2012 3:05 AM

 I think the next step is for the XHR Editors to create a TR version
 using the WD template so that everyone can see exactly what is being
 proposed for publication as a TR. Please create that version as soon as
 you can so that this CfC can be based on that version (rather than the
 ED) and reply with the URL of the TR version.

 (Please use 6 December 2012 as the publication date.)

>>> We prepared a proposed TR version at:
>>> http://dvcs.w3.org/hg/xhr/raw-**file/tip/TR/Overview.html
>>>
>>
>> Thanks Jungkee.
>>
>> All - 
>> >
>> is the
>> document proposed for publication as a TR and thus is the basis for this
>> CfC.
>>
>
> I object to this publication because of this change:
>
> http://dvcs.w3.org/hg/xhr/rev/**2341e31323a4
>
> pushed with a misleading commit message.
>

since you don't say what is misleading, and since commit messages are
irrelevant for W3C process, this  objection is immaterial

Re: [admin] XHR ED Boilerplate

[Glenn Adams]

On Fri, Nov 23, 2012 at 2:22 PM, Ian Hickson  wrote:

> What I don't really understand, though, is why any of this is needed at
> all. What value is the W3C adding by creating these forks?
>

The problem as I see it is that the WHATWG documents are "living documents"
and never final per se.

If the WHATWG documents were published (by WHATWG) as fixed snapshots
during their lifecycle, then perhaps it wouldn't be necessary for the W3C
to create snapshots.

For business and legal purposes, it is often a requirement to have such
snapshots that are known to never change.

Re: [admin] XHR ED Boilerplate

[Glenn Adams]

Is Anne the *sole* author? Did the WG or others not contribute any text or
suggested text to the spec? It seems like a bit of a slippery slope to
attempt to designate a sole author for any W3C product. You might want to
check with the pubs team on this matter.

On Fri, Nov 23, 2012 at 11:44 AM, Arthur Barstow wrote:

> [ Sorry for the delayed response, I was choking on some turkey ... ]
>
> Here's what I did for the URL spec re the boilerplate to help address the
> "attribution issue" re Anne and WHATWG:
>
> [[
> 
> >
>
> This Version:
>
> http://dvcs.w3.org/hg/url/raw-**file/tip/Overview.html
> Latest WHATWG Version:
>http://url.spec.whatwg.org/
> Previous Versions:
>
> http://www.w3.org/TR/2012/ED-**url-20120524/
> Author:
>Anne van Kesteren 
> Editor:
>Web Applications Working Group 
> Former editors:
>Adam Barth 
>Erik Arvidsson 
>Michael[tm] Smith 
> ]]
>
> In the case of XHR, the new Editors would be listed as Editors and if they
> made contributions to the spec, they would also be added to the Author list
> too.
>
> If something like that would not be acceptable for the XHR ED, what
> specific change(s) do you request?
>
> -Thanks, AB
>
>
>
>

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Fri, Nov 23, 2012 at 10:28 AM, Adam Barth  wrote:

> On Fri, Nov 23, 2012 at 9:11 AM, Glenn Adams  wrote:
> > On Fri, Nov 23, 2012 at 9:36 AM, Adam Barth  wrote:
> >> My concern is not about copyright.  My concern is about passing off
> >> Anne's work as our own.
> >
> > As I have pointed out above, W3C specs do not track authorship or
> individual
> > contributions to the WG process. If Anne performed his work as author in
> the
> > context of participating in the W3C process,
>
> This premise is false.  We're discussing the work that he is currently
> performing outside the W3C process.  Specifically, the changes noted
> as "Merge Anne's change" in the past 11 days:
>
> http://dvcs.w3.org/hg/xhr/shortlog


How is this different from the process being used in the HTML WG w.r.t.
bringing WHATWG ongoing work by Ian back into the W3C draft. It seems like
whatever solution is used here to satisfy Anne's concerns should be
coordinated with Ian and the HTML5 editor team so that we don't end up with
two methods for acknowledgment.

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Fri, Nov 23, 2012 at 10:23 AM, Anne van Kesteren wrote:

> On Fri, Nov 23, 2012 at 6:11 PM, Glenn Adams  wrote:
> > As I have pointed out above, W3C specs do not track authorship or
> individual
> > contributions to the WG process. If Anne performed his work as author in
> the
> > context of participating in the W3C process, ...
>
> It seems you are missing the fact that I am neither a Member nor an
> Invited Expert of this WG since August this year.
>
> The W3C does have the legal right to publish my work, since I publish
> it under CC0, but the way the W3C goes about it is not appreciated.
>

I see nothing inconsistent or disingenuous with regard to W3C process here.
There seems to be a suggestion here that the process is broken, and I just
don't see that.

If you as a contributor wish to have more prominent mention in the W3C
version, then it would be appropriate for you to discuss this with the
current editors. Since it sounds like this is a cooperative process, I
would expect you and the editors to find a satisfactory solution.

However, I think this solution need not include making a normative
reference to the ongoing WHATWG work in this area. It certainly wouldn't
hurt to include an informative reference, with sufficient qualification as
to why that reference is used.

G.

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Fri, Nov 23, 2012 at 9:36 AM, Adam Barth  wrote:

> My concern is not about copyright.  My concern is about passing off
> Anne's work as our own.
>

As I have pointed out above, W3C specs do not track authorship or
individual contributions to the WG process. If Anne performed his work as
author in the context of participating in the W3C process, then there is no
obligation to acknowledge that, though there is a long standing practice of
including an Acknowledgments section or paragraph that enumerates
contributors. I would think that listing Anne as Editor or Former Editor
and listing Anne in an Acknowledgments paragraph should be entirely
consistent with all existing W3C practice.

Are you asking for more than this? And if so, then what is the basis for
that?

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth  wrote:

> On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger  wrote:
> > On 11/22/2012 02:01 PM, Arthur Barstow wrote:
> >> TheXHR Editors  would  like to publish a new WD of XHR and this is a
> >> Call for  Consensus to do so using the following ED (not yet using the
> >> WD template) as the basis
> >> .
> >>
> >> Agreement to this proposal: a) indicates support for publishing a new
> >> WD; and b) does not necessarily indicate support of the contents of the
> >> WD.
> >>
> >> If you have any comments or concerns about this proposal, please reply
> >> to this e-mail by December 29 at the latest.
> >>
> >> Positive response to this CfC is preferred and encouraged and silence
> >> will be assumed to mean agreement with the proposal.
> >
> > I object unless the draft contains a clear pointer to the canonical spec
> on
> > whatwg.org.
>
> I agree.  The W3C should not be in the business of plagiarizing the
> work of others.
>

Are you claiming that the W3C is in the business of plagiarizing?


>
> plagiarism. n. The practice of taking someone else's work or ideas and
> passing them off as one's own.



>
> The Status of this Document section should state clearly that this
> document is not an original work of authorship of the W3C.


The SotD section need only refer to the working group that produced the
document. Authorship is not noted or tracked in W3C documents.

If Anne's work was submitted to and prepared in the context of the WebApps
WG, then it is a product of the WG, and there is no obligation to refer to
other, prior or variant versions.

Referring to an earlier, draft version published outside of the W3C process
does not serve any purpose nor is it required by the W3C Process.

If there is a question on the status of the Copyright declaration of the
material or its origin, then that should be taken up by the W3C Pubs team.

G.

Re: CfC: publish WD of XHR; deadline November 29

[Glenn Adams]

On Thu, Nov 22, 2012 at 6:27 AM, Anne van Kesteren  wrote:

> > If you have any comments or concerns about this proposal, please reply to
> > this e-mail by December 29 at the latest.
>
> Putting my name as former editor while all the text is either written
> by me or copied from me seems disingenuous.
>

note that the label "editor" does not imply authorship; authors of W3C
specs do not necessarily correspond to editors;

in other cases in the W3C where editors change over the document's
lifetime, all of the editors are often listed without marking which are
current and which are not current; perhaps that would serve here, i.e.,
just include Anne in the list of editors

Re: [admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]

[Glenn Adams]

Unless I've missed it, I don't believe the #PubRules provides guidelines on
what documents are referenced by a spec and whether the reference is
normative or non-normative. If I'm wrong, please point out the policy or
pubrules text that addresses this issue.

Just to be clear, I don't object to including a non-normative reference to
the WHATWG variant specification; however, if it is to be a normative
reference, I'd like to insist it be the official W3C document that is
referenced.

On Fri, Nov 16, 2012 at 7:14 AM, Arthur Barstow wrote:

> The W3C's process documents (e.g. #PubRules) define the policies for
> publications and this issue will be addressed if/when the CR is actually
> published.
>
> WebApps is simply a user of the publication policy. If you want to discuss
> W3C processes such as PubRules, please use some other list - and not any of
> WebApps' lists - such as public-w3cprocess #ProcCG.
>
> -Thanks, AB
>
> #PubRules 
> <http://www.w3.org/2005/07/**pubrules?uimode=filter<http://www.w3.org/2005/07/pubrules?uimode=filter>
> >
> #ProcCG 
> <http://lists.w3.org/Archives/**Public/public-w3process/<http://lists.w3.org/Archives/Public/public-w3process/>
> >
>
> On 11/16/12 8:51 AM, ext Ms2ger wrote:
>
>> I object to making such a change.
>>
>> On 11/16/2012 02:32 PM, Glenn Adams wrote:
>>
>>> Before going to CR, I believe the [HTML] entry in the references section
>>> needs to be changed to reference an appropriate W3C specification. A
>>> present, it reference a non-W3C document.
>>>
>>
>

Re: Call for Consensus: CORS to Candidate Recommendation

[Glenn Adams]

Cox will file an FO (as a W3C member) if it is not fixed.

On Fri, Nov 16, 2012 at 6:51 AM, Ms2ger  wrote:

> I object to making such a change.
>
>
> On 11/16/2012 02:32 PM, Glenn Adams wrote:
>
>> Before going to CR, I believe the [HTML] entry in the references section
>> needs to be changed to reference an appropriate W3C specification. A
>> present, it reference a non-W3C document.
>>
>> On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow > >wrote:
>>
>>  On 11/15/12 5:31 PM, ext Hill, Brad wrote:
>>>
>>>
>>>> I have placed a draft for review at:
>>>>
>>>> http://www.w3.org/2011/webappsec/cors-draft/<http://www.w3.org/2011/**webappsec/cors-draft/>
>>>> <http://**www.w3.org/2011/webappsec/**cors-draft/<http://www.w3.org/2011/webappsec/cors-draft/>
>>>> >
>>>>
>>>>
>>>> And this is a Call for Consensus among the WebAppSec and WebApps WGs to
>>>> take this particular text (with necessary additions to the Status of
>>>> this
>>>> Document section if approved) forward to Candidate Recommendation.
>>>>
>>>>
>>>>  I support this CfC although I am wondering about the CR exit criteria.
>>>
>>> Do you expect to re-use the CSP1.0 criteria:
>>>
>>> [[
>>> The entrance criteria for this document to enter the Proposed
>>> Recommendation stage is to have a minimum of two independent and
>>> interoperable user agents that implementation all the features of this
>>> specification, which will be determined by passing the user agent tests
>>> defined in the test suite developed by the Working Group.
>>> ]]
>>>
>>> My preference is what WebApps has used in other CRs because I think it is
>>> clearer that a single implementation is not required to pass every test
>>> but
>>> that at least two implementations must pass every test. F.ex.:
>>>
>>> 
>>> <http://www.w3.org/TR/2012/CR-websockets-20120920/#crec<http://www.w3.org/TR/2012/CR-**websockets-20120920/#crec>
>>> http://www.w3.org/TR/2012/CR-websockets-20120920/#crec>
>>> >
>>>
>>>>
>>>>
>>> -Thanks, AB
>>>
>>>
>>>
>>>
>>>
>>
>
>

Re: Call for Consensus: CORS to Candidate Recommendation

[Glenn Adams]

Before going to CR, I believe the [HTML] entry in the references section
needs to be changed to reference an appropriate W3C specification. A
present, it reference a non-W3C document.

On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow wrote:

> On 11/15/12 5:31 PM, ext Hill, Brad wrote:
>
>>
>> I have placed a draft for review at:
>>
>> http://www.w3.org/2011/**webappsec/cors-draft/
>>
>> And this is a Call for Consensus among the WebAppSec and WebApps WGs to
>> take this particular text (with necessary additions to the Status of this
>> Document section if approved) forward to Candidate Recommendation.
>>
>>
> I support this CfC although I am wondering about the CR exit criteria.
>
> Do you expect to re-use the CSP1.0 criteria:
>
> [[
> The entrance criteria for this document to enter the Proposed
> Recommendation stage is to have a minimum of two independent and
> interoperable user agents that implementation all the features of this
> specification, which will be determined by passing the user agent tests
> defined in the test suite developed by the Working Group.
> ]]
>
> My preference is what WebApps has used in other CRs because I think it is
> clearer that a single implementation is not required to pass every test but
> that at least two implementations must pass every test. F.ex.:
>
>
> 
> >
>
> -Thanks, AB
>
>
>
>

Re: [admin] Call for Editor for DOM4 REC track spec

[Glenn Adams]

It is worth noting that this is a critical path blocker for publishing
HTML5 as a REC.

On Fri, Sep 28, 2012 at 2:59 AM, Arthur Barstow wrote:

> Hi All,
>
> The current Editors of the DOM4 spec are not interested in moving that
> spec toward Recommendation (in the context of WebApps WG). Consequently, we
> need an Editor(s) to work on the DOM4 Recommendation track document.
>
> If you are interested in this Editor position and have relevant
> experience, please contact me offlist.
>
> -Thanks, ArtB
>
> [DOM4] 
> 
> >
>
>
>

Re: [XHR] Setting the User-Agent header

[Glenn Adams]

On Wed, Sep 5, 2012 at 12:03 PM, Mark Nottingham  wrote:

> The current draft of XHR2 doesn't allow clients to set the UA header.
>

Presumably, by "clients" you mean client-side script, and not "the [client]
implementation of the UA".


>
> That's unfortunate, because part of the intent of the UA header is to
> identify the software making the request, for debugging / tracing purposes.
>

Since client-side script, whether in a library referenced by a page or
directly from the page, is not part of the UA, then it should not be able
to modify the UA string.


> Given that lots of libraries generate XHR requests, it would be natural
> for them to identify themselves in UA, by appending a token to the
> browser's UA (the header is a list of product tokens).  As it is, they have
> to use a separate header.
>

And, IMO, should stay that way (use a separate header).

Re: Lazy Blob

[Glenn Adams]

On Tue, Aug 7, 2012 at 7:38 PM, Glenn Maynard  wrote:

> On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams  wrote:
>
>> I would suggest using a different name than "URLObject". I think that
>> name will cause a lot of head scratching.
>>
>
> No disagreement there; that was just a placeholder.  I'd suggest waiting
> for further input from Anne, Jonas and Arun (the editors of the specs in
> question) before spending much time coming up with a name, though.


sure... i don't have a suggested replacement, but i know a bad name when i
see one; i'll defer to the editors to come up with something reasonable

Re: Lazy Blob

[Glenn Adams]

On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song wrote:

> > > - URLObject represents a resource that can be fetched, FileReader'd,
> > createObjectURL'd, and cloned, but without any knowledge of the contents
> > (no size attribute, no type attribute) and no slice() as URLObjects may
> > not be seekable.
> > > - Blob extends URLObject, adding size, type, slice(), and the notion of
> > representing an immutable piece of data (URLObject might return different
> > data on different reads; Blob can not).
> >
> > +1 from me on this one.
>
> +1.
>
>
> > I get a sense that this could possibly be a consensus position (or at
> > least I'm going to claim that it is so as to get disagreement to
> manifest).
> > Assuming it is, the next steps are:
> >
> > . Having agreed on a solution, do we agree on the problem? (i.e. would
> > this get implemented?)
> > . If so, we can bake this as a standalone delta spec but it would make
> > more sense to me to make the changes directly to the relevant specs,
> > namely FileAPI and XHR. I've copied Anne, Arun, and Jonas - any thought?
> > In either case, I'm happy to provide the content.
>
> Having hammered out a consensus, I would like to contribute to providing
> the
> content.


I would suggest using a different name than "URLObject". I think that name
will cause a lot of head scratching.

Re: Lazy Blob

[Glenn Adams]

On Mon, Aug 6, 2012 at 2:06 PM, Florian Bösch  wrote:

> On Mon, Aug 6, 2012 at 9:33 PM, Glenn Adams  wrote:
>
>> The same reason that a remote blob would be useful with XHR.
>>
> Since you're steadfastly refusing to detail your use case, that'll just
> mean "none" to me.


I feel I don't have any obligation to justify the use of WS any more than
that necessary for XHR. It is simply short-sighted to define a remote blob
only for XHR. If you can't see that, then let's not waste our time
continuing this thread.

Re: Lazy Blob

[Glenn Adams]

On Mon, Aug 6, 2012 at 1:31 PM, Florian Bösch  wrote:

> On Mon, Aug 6, 2012 at 8:39 PM, Glenn Adams  wrote:
>
>> I'll leave the translation of "IM protocol" to "user facing use case" as
>> homework for the reader. It is trivial. My intent is to show a use case
>> where one would use a persistent connection and a series of send/response
>> messages that easily maps to WS. Instant Messaging is such a use case.
>>
> What is it exactly that requires you to use a remote blob with type blob
> in the browser over a WS you cannot achieve with a WS and array buffers?
>

The same reason that a remote blob would be useful with XHR.

Re: Lazy Blob

[Glenn Adams]

On Mon, Aug 6, 2012 at 11:27 AM, Ian Hickson  wrote:

> On Mon, 6 Aug 2012, Glenn Adams wrote:
> >
> > I did share a couple of use cases in my response to Ian:
> >
> > > I will let Robin and Jungkee reply to the more general use case
> > > requirements. As far as WS is concerned, I don't see any impact of
> > > this thread on the WS API or WSP specs, its really simply an
> > > application of WS/WSP to "remote/lazy blobs".
> > >
> > > Clearly, there are many high level use cases that involve a repetitive
> > > send/response message paradigm, which can certainly be implemented
> > > with XHR, but some application authors would prefer using WS for
> > > various efficiency reasons. My suggestion is essentially: if we are
> > > going to define a remote blob bound to an XHR source for a one-shot
> > > send-response, then perhaps we should define a remote blob bound to a
> > > WS source for multiple send-response pairs. For example, a symmetric
> > > presence protocol or IM protocol would typically fall into this usage
> > > category.
> > >
> > > Using remote blobs for either the send or response data (or both)
> > > would be useful for certain architectures and provide more deployment
> > > flexibility and perhaps greater efficiencies.
>
> Those are still not use cases, for the record. I tried explaining what a
> use case was here:
>
> http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0302.html
> http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0288.html


I'll leave the translation of "IM protocol" to "user facing use case" as
homework for the reader. It is trivial. My intent is to show a use case
where one would use a persistent connection and a series of send/response
messages that easily maps to WS. Instant Messaging is such a use case.

Re: Lazy Blob

[Glenn Adams]

On Mon, Aug 6, 2012 at 6:53 AM, Robin Berjon  wrote:

> So if you do have a use case, by all means please share it. If not, I
> maintain that you simply have no grounds for objection.
>

I did share a couple of use cases in my response to Ian:

On Thu, Aug 2, 2012 at 11:39 AM, Glenn Adams  wrote:

>
> On Thu, Aug 2, 2012 at 11:26 AM, Ian Hickson  wrote:
>
>> On Thu, 2 Aug 2012, Glenn Adams wrote:
>> >
>> > Are you asking for use cases for a remote/lazy blob in general? i.e., as
>> > would apply to the proposed XHR usage and any other underlying supported
>> > data source? or are you asking about high level use cases that are
>> > particular to a WS binding but not an XHR binding?
>>
>> Both would be useful, but my primary concern is Web Sockets, since I edit
>> that spec. Before I can consider proposals that affect Web Sockets, I need
>> to know what use case it is we're trying to address.
>>
>
> I will let Robin and Jungkee reply to the more general use case
> requirements. As far as WS is concerned, I don't see any impact of this
> thread on the WS API or WSP specs, its really simply an application of
> WS/WSP to "remote/lazy blobs".
>
> Clearly, there are many high level use cases that involve a repetitive
> send/response message paradigm, which can certainly be implemented with
> XHR, but some application authors would prefer using WS for various
> efficiency reasons. My suggestion is essentially: if we are going to
> define a remote blob bound to an XHR source for a one-shot send-response,
> then perhaps we should define a remote blob bound to a WS source for
> multiple send-response pairs. For example, a symmetric presence protocol or
> IM protocol would typically fall into this usage category.
>
> Using remote blobs for either the send or response data (or both) would be
> useful for certain architectures and provide more deployment flexibility
> and perhaps greater efficiencies.
>
>

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 11:26 AM, Ian Hickson  wrote:

> On Thu, 2 Aug 2012, Glenn Adams wrote:
> >
> > Are you asking for use cases for a remote/lazy blob in general? i.e., as
> > would apply to the proposed XHR usage and any other underlying supported
> > data source? or are you asking about high level use cases that are
> > particular to a WS binding but not an XHR binding?
>
> Both would be useful, but my primary concern is Web Sockets, since I edit
> that spec. Before I can consider proposals that affect Web Sockets, I need
> to know what use case it is we're trying to address.
>

I will let Robin and Jungkee reply to the more general use case
requirements. As far as WS is concerned, I don't see any impact of this
thread on the WS API or WSP specs, its really simply an application of
WS/WSP to "remote/lazy blobs".

Clearly, there are many high level use cases that involve a repetitive
send/response message paradigm, which can certainly be implemented with
XHR, but some application authors would prefer using WS for various
efficiency reasons. My suggestion is essentially: if we are going to define
a remote blob bound to an XHR source for a one-shot send-response, then
perhaps we should define a remote blob bound to a WS source for multiple
send-response pairs. For example, a symmetric presence protocol or IM
protocol would typically fall into this usage category.

Using remote blobs for either the send or response data (or both) would be
useful for certain architectures and provide more deployment flexibility
and perhaps greater efficiencies.

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 11:19 AM, Ian Hickson  wrote:

> On Thu, 2 Aug 2012, Glenn Adams wrote:
> >
> > I was referring to
> > http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html
> >
> > While that message does not specifically refer to a full-duplex comm
> > path, it states the general problem in terms of "It is increasingly
> > common that data may flow from a server to an in-browser page, that may
> > then pass that data on to another in-browser page (typically running at
> > a different origin). In a many cases, such data will be captured as
> > Blobs."
>
> The above isn't a use case, it's a description of an architectural design,
> the first step towards the description of a solution.
>
> What I'm trying to understand is the underlying _problem_ that the
> technology is trying to solve. Something like "I want to be able to sell
> plane tickets for people to go on holiday", say. Or "I want to provide a
> service to users that lets them merge data from a medical drugs database
> and a patient database, without giving me their credentials to those
> databases". Or some such. I don't know exactly what the use case here
> would be, hence my questions.
>

Are you asking for use cases for a remote/lazy blob in general? i.e., as
would apply to the proposed XHR usage and any other underlying supported
data source? or are you asking about high level use cases that are
particular to a WS binding but not an XHR binding?

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 11:09 AM, Florian Bösch  wrote:

> On Thu, Aug 2, 2012 at 6:37 PM, Glenn Adams  wrote:
>
>> I am not proposing a "particular browser supported semantic" for a
>> "specific implementation on the server". I have suggested, by way of
>> example, two particular patterns be supported independently of any such
>> implementation. I did not restrict the results to just those patterns in
>> case someone wishes to generalize. That is little different from the
>> proposed or implied XHR patterns being discussed.
>>
>
> So I'll take a stab, the remote blob resource/range protocol over WS 1.0:
>
> 1) A websocket to a URL is opened by the browser, the path and query of
> the URL is interpreted to specify a resource.
> 2) During the lifetime of a websocket session onto a wsblob resource, the
> resource is guaranteed to be reflected unchanged to the session, it cannot
> be changed, appended or removed.
> 3) The client has to send these bytes "" as a first message
> 4) The server has to respond with a "" message to
> indicate that he understands this protocol and indicate the byte length of
> the resource.
> 5) after successful setup the client may request ranges from the server by
> sending this message: "", start and end have to be in
> range of the byte resource.
> 6) The server will respond to each range request in the form of
> "" in case that a range request is valid, the
> length of  has to be start - end. In case a range is not valid the
> server will respond with ".
>
> These are the protocol field definitions:
> handshake := "wsblob"
> length := unsigned int 4 bytes
> start := unsigned int 4 bytes
> end := unsigned int 4 bytes
> bytes := string of bytes
> range := 0x01
> invalid := 0x02
>

ok, that is fine, but I never suggested limiting the semantics of
interchange to a "resource/range protocol"; as is clear, the above
application specific protocol does in fact use the "multiple" pattern I
described, i.e., each interchange consists of a pair of send-response
messages, each of which can be encapsulated in a blob, and each response
blob could be implemented as a remotable 'promise' encapsulating a send
blob and its resultant response blob;

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 11:01 AM, Ian Hickson  wrote:

> On Thu, 2 Aug 2012, Glenn Adams wrote:
> > >
> > > Sorry, I was vague. What I mean is what user-facing problem is it that
> > > we're trying to solve?
> >
> > see DAR's initial message in this thread; bringing WS into scope doesn't
> > change the problem statement, it merely enlarges the solution space, or
> > keeps it from being unnecessarily narrow
>
> Do you have a link to a specific message? I went through the archives and
> couldn't find any e-mails in this thread that came close to describing a
> use case for anything, let alone anything that would be related to
> persistent bi-directional full-duplex communication with a remote server.
>

I was referring to [1].

[1] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html

While that message does not specifically refer to a full-duplex comm path,
it states the general problem in terms of "It is increasingly common that
data may flow from a server to an in-browser page, that may then pass that
data on to another in-browser page (typically running at a different
origin). In a many cases, such data will be captured as Blobs."

It goes on to describe a solution space oriented towards XHR as the comm
path. It occurred to me that the same problem could apply to WS comm path
patterns, which is why I suggested enlarging the solution space to include
WS.

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 10:04 AM, Florian Bösch  wrote:

> On Thu, Aug 2, 2012 at 5:58 PM, Glenn Adams  wrote:
>
>> All WS usage requires a particular (application specific) implementation
>> on the server, does it not? Notwithstanding that fact, such usage will fall
>> into certain messaging patterns. I happened to give an example of two
>> possible message patterns and showed how the proposal under discussion
>> could address those patterns. It is not necessary to marry my proposal to a
>> specific sub-protocol on WS in order to provide useful functionality that
>> can be exploited by applications that use those functions.
>>
>
> If you wish to introduce a particular browser supported semantic for which
> a specific implementation on the server is required, then people should be
> able to consult a standard that tells them how they have to provide this
> implementation. Therefore it is quite necessary to marry your desire to
> extend remote blobs  to WS to a protocol, otherwise you'll have a browser
> implemented protocol that nobody knows how to implement.
>

I am not proposing a "particular browser supported semantic" for a
"specific implementation on the server". I have suggested, by way of
example, two particular patterns be supported independently of any such
implementation. I did not restrict the results to just those patterns in
case someone wishes to generalize. That is little different from the
proposed or implied XHR patterns being discussed.

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 9:51 AM, Florian Bösch  wrote:

> On Thu, Aug 2, 2012 at 5:45 PM, Glenn Adams  wrote:
>
>> No it hasn't. If you want a real world use case it is this: my
>> architectural constraints as an author for some particular usage requires
>> that I use WS rather than XHR. I wish to have support for the construct
>> being discussed with WS. How is that not a real world requirement?
>>
>
> Your particular use-case of content/range aquisition over WS requires a
> particular implementation on the server in order to understand the WS
> application layer protocol. This particular implementation on the server of
> yours is not implemented by any other common hosting infrastructure based
> on any kind of existing standard. You should specify this particular
> protocol standard to be used on top of WS first before you can even discuss
> how your custom implementation of this protocol justifies enshrining it in
> a browser standard.
>

All WS usage requires a particular (application specific) implementation on
the server, does it not? Notwithstanding that fact, such usage will fall
into certain messaging patterns. I happened to give an example of two
possible message patterns and showed how the proposal under discussion
could address those patterns. It is not necessary to marry my proposal to a
specific sub-protocol on WS in order to provide useful functionality that
can be exploited by applications that use those functions.

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 2:36 AM, Robin Berjon  wrote:

> On Aug 1, 2012, at 22:13 , Glenn Adams wrote:
> > The subject line says Lazy Blob, not Lazy Blob and XHR. For the record,
> I will object to a LazyBlob solution that is tied solely to XHR, so deal
> with it now rather than later.
>
> Objections need to be built on something — just objecting for the fun of
> it does not carry some weight. Up to this point, you have provided no real
> world use case that requires the feature you propose and your sole
> justification for the whole subthread is that you don't like the idea.
>

Are you saying I am objecting for the fun of it? Where did I say I don't
like the idea? You'd best reread my messages.


>
> As far as I'm concerned, barring the introduction of better arguments the
> objection is dealt with hic et nunc.
>

No it hasn't. If you want a real world use case it is this: my
architectural constraints as an author for some particular usage requires
that I use WS rather than XHR. I wish to have support for the construct
being discussed with WS. How is that not a real world requirement?

Re: Lazy Blob

[Glenn Adams]

On Thu, Aug 2, 2012 at 1:04 AM, Ian Hickson  wrote:

> On Thu, 2 Aug 2012, Glenn Adams wrote:
> > >
> > > I don't really care about the XHR side of this (happy to let Anne
> > > figure that out), but since WebSockets was mentioned: what's the use
> > > case that involves Web Socket? I don't really understand what problem
> > > we're trying to solve here.
> >
> > i would like to support two use cases:
> >
> > (1) simple - single blob send, single blob response
> > (2) multiple - multiple instances of simple, i.e., send/response pairs
>
> Sorry, I was vague. What I mean is what user-facing problem is it that
> we're trying to solve?


see DAR's initial message in this thread; bringing WS into scope doesn't
change the problem statement, it merely enlarges the solution space, or
keeps it from being unnecessarily narrow

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 10:44 PM, Ian Hickson  wrote:

> On Wed, 1 Aug 2012, Glenn Adams wrote:
> >
> > Of course, implementers are free to ignore whatever they want, but last
> > time I checked, the W3C was a consensus based standards organization
> > which means agreement needs to be reached on what specs go out the door
> > and what are in those specs.
>
> Doesn't really matter what's in the specs going "out the door" if it's not
> what's implemented...
>
> I don't really care about the XHR side of this (happy to let Anne figure
> that out), but since WebSockets was mentioned: what's the use case that
> involves Web Socket? I don't really understand what problem we're trying
> to solve here.
>

based on the pattern proposed by

partial interface BlobBuilder {
Blob getBlobFromURL (XMLHttpRequest xhr);
};

i would like to support two use cases:

(1) simple - single blob send, single blob response
(2) multiple - multiple instances of simple, i.e., send/response pairs

these could be handled with the following:

partial interface BlobBuilder {
// simple
Blob getBlobFromSource (WebSocket ws, Blob send);
// multiple
Blob getBlobFromSource (WebSocket ws, EventHandler sendHandler);
};

in the simple case, the creator of the lazy blob provides the initial send
blob, which is sent by the underlying lazy blob implementation upon a read
on the lazy blob, then the next (and only) response blob is returned as a
result from the read

in the multiple case, the creator of the lazy blob provides an event
handler to invoke to send a blob corresponding to a read on the lazy blob,
thus providing for multiple send/receive blob message pairs, with one lazy
blob for each pair

of course, the simple case could be folded into the multiple case, leaving
only one method to define:

partial interface BlobBuilder {
Blob getBlobFromSource (WebSocket ws, EventHandler sendHandler);
};

a use of this might be as follows:

var bb = new BlobBuilder();
var ws = new WebSocket("ws://example.com:/test");
var lb = [];
ws.onopen = function() {
lb.push ( bb.getBlobFromSource(ws, function() {
ws.send(getSendMessageAsBlob(1)); }) );
lb.push ( bb.getBlobFromSource(ws, function() {
ws.send(getSendMessageAsBlob(2)); }) );
lb.push ( bb.getBlobFromSource(ws, function() {
ws.send(getSendMessageAsBlob(3)); }) );
setTimeout(sendAndReceive);
}
function getSendMessageAsBlob(msgNum) {
return new Blob ( [ String(msgNum) ] );
}
function sendAndReceive() {
var numMsgs = 0;
var numBytes = 0;
// trigger read on queued lazy blobs


while ( lb.length > 0 ) {
b = lb.shift();
// read on size triggers stored send 'promise'


numBytes += b.size;
numMsgs += 1;
}
alert('Received ' + numMsgs + ' messages, containing ' + numBytes + '
bytes.');
ws.close();
}

of course, this example make use of a particular message paradigm
(send/recv pairs); while this may capture only a subset of interchange
patterns, one could easily generalize the above to provide more flexibility;

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 2:13 PM, Glenn Adams  wrote:

>
> On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard  wrote:
>
>> Can we please stop saying "lazy blob"?  It's a confused and confusing
>> phrase.  Blobs are "lazy" by design.
>>
>> On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams  wrote:
>>
>>> So? Why should lazy blob be specific to HTTP specific semantics when an
>>> arbitrary URL is not specific to HTTP?
>>>
>>
>> XHR is no more specific to HTTP than it is to XML.  It serves as the
>> primary JavaScript API for performing generic network fetches.  WebSockets
>> has an entirely different API from blobs, and bringing them up is only
>> derailing the thread.
>>
>
> The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I
> will object to a LazyBlob solution that is tied solely to XHR, so deal with
> it now rather than later.
>

Just to make it clear, I support the idea of defining a "lazy blob"
mechanism. However, I am not satisfied that a solution that is tied solely
to XHR is sufficient. I would like to see a mechanism that supports both
XHR and WS [and others?]. Despite the repeated claims of Florian and GlennM
that it doesn't make sense, etc., I think it does make sense and can be
reasonably (and simply) defined to handle such use cases. If necessary I
can volunteer a strawman to that end. However, I would prefer that DAR or
other proposers take the time to consider this use case and factor it into
their proposals.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 9:35 PM, Glenn Maynard  wrote:

> On Wed, Aug 1, 2012 at 9:54 PM, Glenn Adams  wrote:
>
>> I don't particularly care if a default behavior for WS is provided that
>> buffers the entire read stream.
>>
>
> Sorry, but that doesn't make sense.  You don't access a message-based
> protocol (Web Sockets) using a character-based API (Blob).  They're utterly
> different APIs.
>

Have you read the Blob interface spec? To quote:

This interface represents *immutable* raw data. It provides a method to
slice <http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice> data objects
between ranges of bytes into further chunks of raw data.

The last time I checked, bytes are bytes, not characters. The fact that the
interface provides access to those bytes via a particular string encoding
is irrelevant.



>
> I'll leave the details of defining this to the proposers of lazy blob.
>>
>
> You're free to come up with your own proposal, of course, and editors and
> vendors will choose among them (or come up with something else, or reject
> the idea entirely) as they always do, but others are not obligated to twist
> their proposals to your demands.
>

Of course, implementers are free to ignore whatever they want, but last
time I checked, the W3C was a consensus based standards organization which
means agreement needs to be reached on what specs go out the door and what
are in those specs. Since this is a W3C ML and not an implementers' forum,
then I will continue to assume that the W3C process applies.

There is a fixed obligation for editors and WG to address comments. They
can't simply be rejected because they require work on the part of the
editors or proposers.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 2:35 PM, Florian Bösch  wrote:

> On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams  wrote:
>
>> The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I
>> will object to a LazyBlob solution that is tied solely to XHR, so deal with
>> it now rather than later.
>>
>
> Then you better get onto specifying a resource/range transfer protocol on
> top of websockets alongside with web-server modules/extensions to be able
> to understand that protocol, because other than that there is no way that
> you'll get what you want.
>

I don't think so. There is nothing about Blob that would require a data
source to implement range access. Blob.slice() does not require the
underlying source to provide range access. The source could be read in
entirety and buffered by a Blob instance.

If a reasonable WS enabled mechanism were defined for a "Lazy Blob" that
permitted an application injected range access, then that could be used to
perform actual range access. There is no need for WS/WSP to support those
semantics directly.

I don't particularly care if a default behavior for WS is provided that
buffers the entire read stream. It's fine to mandate that an application
defined function implement those semantics on a WS instance.

My concern is that use of WS be recognized as a legitimate source for
filling a lazy blob, and that an author should have an option to use WS,
depending on app injected code as needed, instead of mandating XHR for this
purpose. I'll leave the details of defining this to the proposers of lazy
blob.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard  wrote:

> Can we please stop saying "lazy blob"?  It's a confused and confusing
> phrase.  Blobs are "lazy" by design.
>
> On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams  wrote:
>
>> So? Why should lazy blob be specific to HTTP specific semantics when an
>> arbitrary URL is not specific to HTTP?
>>
>
> XHR is no more specific to HTTP than it is to XML.  It serves as the
> primary JavaScript API for performing generic network fetches.  WebSockets
> has an entirely different API from blobs, and bringing them up is only
> derailing the thread.
>

The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I
will object to a LazyBlob solution that is tied solely to XHR, so deal with
it now rather than later.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 1:54 PM, Florian Bösch  wrote:

> On Wed, Aug 1, 2012 at 9:50 PM, Glenn Adams  wrote:
>
>> Further, a default behavior in the absence of such an injection might be
>> defined simply to read data from the WS and stuff into the blob.
>>
> Which kind of defeats the purpose because you wanted to read ranges, so
> not a whole resource has to be transferred, and you can already read binary
> data from websockets if you wish to do that, without having to invent
> another blob.


A default behavior does not have to handle all uses cases. App specific
code injection could handle this if the author wished it, provided a
mechanism supported it.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 1:47 PM, Glenn Adams  wrote:

>
> On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch  wrote:
>
>>  On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams  wrote:
>>
>>> So? Why should lazy blob be specific to HTTP specific semantics when an
>>> arbitrary URL is not specific to HTTP?
>>>
>>
>> So if you want to have a lazy reader on Websockets you have either:
>> 1) respecify the websocket protocol to include content semantics for
>> accessing resources defined by an URL and having a specified size OR
>> 2) define an additional protocol on top of websockets, which websockets
>> know nothing about, that allows a custom implementation at the server side
>> to respond in a meaningful fashion to resource range requests.
>>
>
> OR define a mechanism for LazyBlob that permits the injection of app
> specific code into the underlying LazyBlob reader loop.
>

Further, a default behavior in the absence of such an injection might be
defined simply to read data from the WS and stuff into the blob.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch  wrote:

> On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams  wrote:
>
>> So? Why should lazy blob be specific to HTTP specific semantics when an
>> arbitrary URL is not specific to HTTP?
>>
>
> So if you want to have a lazy reader on Websockets you have either:
> 1) respecify the websocket protocol to include content semantics for
> accessing resources defined by an URL and having a specified size OR
> 2) define an additional protocol on top of websockets, which websockets
> know nothing about, that allows a custom implementation at the server side
> to respond in a meaningful fashion to resource range requests.
>

OR define a mechanism for LazyBlob that permits the injection of app
specific code into the underlying LazyBlob reader loop.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 12:03 PM, Florian Bösch  wrote:

> On Wed, Aug 1, 2012 at 7:57 PM, Glenn Adams  wrote:
>
>> blob = 
>> bb.getBlobFromURL("ws://specifiction.com/image/kitten.png<http://specifiction.com/kitten.png>
>> ")
>>
>
> There is no application layer transfer protocol inherent in websockets.
> Requesting a resource does not have any inherent meaning other than that
> you are opening a "channel" onto /image/kitten.png. Whoever receives that
> request is free to respond to that however he likes. You would need to
> introduce an application layer content protocol on top of websockets, and
> introduce a default websocket server framework capable of understanding
> such content requests. You're not just extending lazy reading to
> websockets. You're putting the burden on yourself to also specify a
> completely new standard application layer protocol for transfer and range
> and acquisition of resources over websocket channels.
>

So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary URL is not specific to HTTP?

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 11:13 AM, Florian Bösch  wrote:

> On Wed, Aug 1, 2012 at 6:51 PM, Glenn Adams  wrote:
>
>> I'm questioning defining a "LazyBlob" that is solely usable with XHR. It
>> would be better to have a more generic version IMO.
>>
> Websockets have no content semantics, therefore any lazy content
> negotiating reader cannot deal with websockets unless an additional
> application layer protocol and implementation on the server side is
> introduced, something that does not exist for websockets otherwise. You
> could for instance implement HTTP over websockets to get the content
> semantics, and if your server gets a websocket request, it could be proxied
> to a domain socket which happend to have a webserver listening which would
> understand the HTTP request and deliver the resource/range.
>
> Now instead of implementing HTTP over websockets over HTTP over sockets,
> you could just use XHRs which implement HTTP over sockets. Which is why
> generalising lazy readers to websockets does not make sense.
>

Given the "Simple approach" suggested by DAR:

partial interface BlobBuilder {
> Blob getBlobFromURL (DOMString url);
> };
> Usage:
> var bb = new BlobBuilder()
> ,   blob = bb.getBlobFromURL("http://specifiction.com/kitten.png";);


I don't see why the following isn't feasible:

blob = 
bb.getBlobFromURL("ws://specifiction.com/image/kitten.png<http://specifiction.com/kitten.png>
")

Or, given the "Using XHR for Options" approach:

partial interface BlobBuilder {
> Blob getBlobFromURL (XMLHttpRequest xhr);
> };
> Usage:
> var bb = new BlobBuilder()
> ,   xhr = new XMLHttpRequest();
> xhr.open("GET", "/kitten.png", true);
> xhr.setRequestHeader("Authorization", "Basic DEADBEEF");
> var blob = bb.getBlobFromURL(xhr);


why one couldn't have:

partial interface BlobBuilder {
Blob getBlobFromURL (WebSocket ws);
};

var bb = new BlobBuilder()
,   ws = new 
WebSocket("ws://specifiction.com/image<http://specifiction.com/kitten.png>
");
ws.onopen = function(){ws.send("kitten.png");}
var blob = bb.getBlobFromURL(ws);

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 10:46 AM, Florian Bösch  wrote:

> On Wed, Aug 1, 2012 at 6:40 PM, Glenn Adams  wrote:
>
>> Why restrict to XHR? How about WebSocket as data source?
>>
> Websockets support array buffers and therefore by extension any blob/file
> object. However as a stream oriented API websockets have no content
> aquisition, negotation, range and transfer semantics unless you prop those
> up by yourself as an application layer protocol.


I'm questioning defining a "LazyBlob" that is solely usable with XHR. It
would be better to have a more generic version IMO.

Re: Lazy Blob

[Glenn Adams]

On Wed, Aug 1, 2012 at 9:44 AM, Glenn Maynard  wrote:

> On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon  wrote:
>
>> var bb = new BlobBuilder()
>
> ,   blob = bb.getBlobFromURL("http://specifiction.com/kitten.png";, "GET",
>> { Authorization: "Basic DEADBEEF" });
>>
>> Everything is the same as the previous version but the method and some
>> headers can be set by enumerating the Object. I *think* that those are all
>> that would ever be needed.
>>
>
> We already have an API to allow scripts to make network requests: XHR.
>  Please don't create a new API that will end up duplicating all of that.
>  However this might be done, it should hang off of XHR.
>

Why restrict to XHR? How about WebSocket as data source?

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Glenn Adams]

On Wed, Jul 11, 2012 at 10:52 AM, Edward O'Connor wrote:

> Art wrote:
>
> > As such, this is a Call for Consensus to publish a Candidate
> > Recommendation of Web Sockets.
>
> Ship it! :)
>

+1

Re: Howto spec

[Glenn Adams]

On Wed, May 23, 2012 at 11:29 AM, Glenn Adams  wrote:

>
> On Wed, May 23, 2012 at 9:55 AM, Dimitri Glazkov wrote:
>
>> This is neat! I especially appreciated the Method/Attribute patterns.
>> I will use this.
>>
>> Should I be concerned about what seems to be a lively competition
>> between ReSpec and Anolis. Do we need this tussle? Can we not just
>> decide which tool to use?
>
>
> editor tools are at the editors' prerogative, so we should not mandate
> specific tools i think
>
> in fact, i am not completely happy with either respec or anolis, and have
> put together something of a hybrid i'm using on cssom*;  in particular,
> what i'm doing is:
>
>- writing all IDL and related documentation in WebIDL format, with
>each top-level definition in a distinct file, while using 'Documentation'
>extended attributes in the WebIDL files that contains both substitution
>patterns and markup, rather akin to javadoc but with different substitution
>keywords that better pertain to the WebIDL usage context;
>- use a driver file with CPP includes, then running (gnu) CPP to
>create a single IDL resource for the subsequent processing
>- use robin's WebIDLParser.js [1] (via node.js) to validate and dump
>JSON representation of IDL
>- use Aria Stewart's (aredridel) HTML5.js parser [2] (via node.js) to
>parse then serialize with substitution replacement based on the JSON IDL,
>e.g.,  is replaced with an HTML5 representation of
>the MediaList IDL, ,
>, , etc., get the
>associated documentation
>- finally use anolis to perform other substitutions, toc generation,
>etc.
>
> the reason I'm doing this is because i prefer embedding documentation in
> IDL sources than embedding IDL in HTML sources; i also want to do all
> processing at authoring time, and not at load time via the ReSpec approach
>
> once i'm satisfied with this approach, i'll post it and document with a
> wiki in case some other editor wishes to use this method; but, again, i
> think which approach is used should be left to specific editors, since it
> affects their productivity
>
> cheers, glenn
>

relevant links

[1] https://github.com/darobin/webidl.js
[2] https://github.com/aredridel/html5

Re: Howto spec

[Glenn Adams]

On Wed, May 23, 2012 at 9:55 AM, Dimitri Glazkov wrote:

> This is neat! I especially appreciated the Method/Attribute patterns.
> I will use this.
>
> Should I be concerned about what seems to be a lively competition
> between ReSpec and Anolis. Do we need this tussle? Can we not just
> decide which tool to use?


editor tools are at the editors' prerogative, so we should not mandate
specific tools i think

in fact, i am not completely happy with either respec or anolis, and have
put together something of a hybrid i'm using on cssom*;  in particular,
what i'm doing is:

   - writing all IDL and related documentation in WebIDL format, with each
   top-level definition in a distinct file, while using 'Documentation'
   extended attributes in the WebIDL files that contains both substitution
   patterns and markup, rather akin to javadoc but with different substitution
   keywords that better pertain to the WebIDL usage context;
   - use a driver file with CPP includes, then running (gnu) CPP to create
   a single IDL resource for the subsequent processing
   - use robin's WebIDLParser.js [1] (via node.js) to validate and dump
   JSON representation of IDL
   - use Aria Stewart's (aredridel) HTML5.js parser [2] (via node.js) to
   parse then serialize with substitution replacement based on the JSON IDL,
   e.g.,  is replaced with an HTML5 representation of
   the MediaList IDL, ,
   , , etc., get the
   associated documentation
   - finally use anolis to perform other substitutions, toc generation, etc.

the reason I'm doing this is because i prefer embedding documentation in
IDL sources than embedding IDL in HTML sources; i also want to do all
processing at authoring time, and not at load time via the ReSpec approach

once i'm satisfied with this approach, i'll post it and document with a
wiki in case some other editor wishes to use this method; but, again, i
think which approach is used should be left to specific editors, since it
affects their productivity

cheers, glenn

Re: Howto spec

[Glenn Adams]

On Wed, May 23, 2012 at 6:45 AM, Anne van Kesteren  wrote:

> Hi,
>
> I have made some updates to the "howto spec" wiki page outlining how
> you should go about writing a specification, with some emphasis on
> specifications for APIs.
>
> http://wiki.whatwg.org/wiki/Howto_spec
>
> In particular the "Patterns" and "Legacy DOM-style" sections are
> probably of interest. I would love to have feedback to see what else
> people would like to see explained or how what is explained thus far
> can be done better.
>

I would like to see more explanation of some statements under the "Legacy
DOM-style" section, particularly:

   - what is the "particular style of defining methods and attributes" that
   is to be discouraged?
   - how does ReSpec.js use or promote the discouraged particulars?

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 10:02 AM, Marcos Caceres
wrote:

> On Thursday, 19 April 2012 at 16:57, Glenn Adams wrote:
>  > thanks Marcos, I drop my objection; regarding the reference to HTML5,
>
> Yay! :)
> > it would be an improvement if you could change section 6.5 from:
> >
> > The concept of origin is defined in [HTML] (
> http://dev.w3.org/2006/waf/widgets-api/#html5).
> >
> > to
> >
> > The concept of origin of a Document object is defined in [HTML] (
> http://dev.w3.org/2006/waf/widgets-api/#html5).
> Done, and committed:
> http://dev.w3.org/2006/waf/widgets-api/#origin


thanks for the "speed of light" resolution! :)

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 9:49 AM, Marcos Caceres  wrote:

> On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote:
> > On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:
> >
> > > > in that case, please record an objection on my part
> > > just to be clear, I mean an objection to publishing as PR unless this
> is clarified; i believe this is an issue because the concept and use of
> origin is (1) very complex and (2) thus prone to misinterpretation; for
> example, it is not well recognized that HTML5 itself does not require a UA
> to send an Origin header in a URL request (see [3])
> > Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web
> Storage). But what does this have to do with Widgets?
>
> Glenn and I discussed this on IRC. Glenn suggested I add the following to
> the definition of a widget instance:
>
>  "The origin of a widget instance is the origin of the Document object
> associated with the widget instance's browsing context."
>
> I agree with Glenns recommendation, so I've go ahead and added that:
>
> http://dev.w3.org/2006/waf/widgets-api/#widget-instance


thanks Marcos, I drop my objection; regarding the reference to HTML5, it
would be an improvement if you could change section 6.5 from:

The concept of origin is defined in
[HTML]<http://dev.w3.org/2006/waf/widgets-api/#html5>
.

to

The concept of origin of a Document object is defined in
[HTML]<http://dev.w3.org/2006/waf/widgets-api/#html5>
.

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 9:04 AM, Glenn Adams  wrote:

>
> On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres 
> wrote:
>
>> On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:
>>
>> >
>> > On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres <
>> marcosscace...@gmail.com (mailto:marcosscace...@gmail.com)> wrote:
>> > > On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
>> > > > Marcos - would you please enumerate the CR's uses of HTML5 and state
>> > > > whether each usage is to a stable part of HTML5?
>> > >
>> > > 3. "When getting or setting the preferences attribute, if the origin
>> of a widget instance is mutable (e.g., if the user agent allows
>> document.domain to be dynamically changed), then the user agent must
>> perform the preference-origin security check. The concept of origin is
>> defined in [HTML]."
>> > > Origin is concept that is well understood - as is the same origin
>> policy used by browsers.
>> >
>> >
>> > TWI [1] does not define "the origin of a widget instance".
>> That's because they are not bound to any particular URI scheme. Just to
>> some origin.
>> > Nor does HTML5. It is also confusing to say that HTML5 defines the
>> 'concept of origin', given that it normatively refers to The Web Origin
>> Concept [2]. TWI needs to be more specific about what aspect of Origin is
>> being referenced and where that specific aspect is defined.
>>
>> As there are no interoperability issues, I don't agree the TWI spec needs
>> to be updated any further. It's just a simple spec and any further
>> clarifications would just be academic.
>> >
>> > [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
>> > [2] http://tools.ietf.org/html/rfc6454
>>
>
> in that case, please record an objection on my part
>

just to be clear, I mean an objection to publishing as PR unless this is
clarified; i believe this is an issue because the concept and use of origin
is (1) very complex and (2) thus prone to misinterpretation; for example,
it is not well recognized that HTML5 itself does not require a UA to send
an Origin header in a URL request (see [3])

[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres wrote:

> On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:
>
> >
> > On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres <
> marcosscace...@gmail.com (mailto:marcosscace...@gmail.com)> wrote:
> > > On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
> > > > Marcos - would you please enumerate the CR's uses of HTML5 and state
> > > > whether each usage is to a stable part of HTML5?
> > >
> > > 3. "When getting or setting the preferences attribute, if the origin
> of a widget instance is mutable (e.g., if the user agent allows
> document.domain to be dynamically changed), then the user agent must
> perform the preference-origin security check. The concept of origin is
> defined in [HTML]."
> > > Origin is concept that is well understood - as is the same origin
> policy used by browsers.
> >
> >
> > TWI [1] does not define "the origin of a widget instance".
> That's because they are not bound to any particular URI scheme. Just to
> some origin.
> > Nor does HTML5. It is also confusing to say that HTML5 defines the
> 'concept of origin', given that it normatively refers to The Web Origin
> Concept [2]. TWI needs to be more specific about what aspect of Origin is
> being referenced and where that specific aspect is defined.
>
> As there are no interoperability issues, I don't agree the TWI spec needs
> to be updated any further. It's just a simple spec and any further
> clarifications would just be academic.
> >
> > [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
> > [2] http://tools.ietf.org/html/rfc6454
>

in that case, please record an objection on my part

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres wrote:

> On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
> > Marcos - would you please enumerate the CR's uses of HTML5 and state
> > whether each usage is to a stable part of HTML5?
> 3. "When getting or setting the preferences attribute, if the origin of a
> widget instance is mutable (e.g., if the user agent allows document.domain
> to be dynamically changed), then the user agent must perform the
> preference-origin security check. The concept of origin is defined in
> [HTML]."
>
> Origin is concept that is well understood - as is the same origin policy
> used by browsers.
>

TWI [1] does not define "the origin of a widget instance". Nor does HTML5.
It is also confusing to say that HTML5 defines the 'concept of origin',
given that it normatively refers to The Web Origin Concept [2]. TWI needs
to be more specific about what aspect of Origin is being referenced and
where that specific aspect is defined.

[1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
[2] http://tools.ietf.org/html/rfc6454

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Tue, Mar 27, 2012 at 3:23 PM, Boris Zbarsky  wrote:

> The spec says:
>
>  Return the HTTP status text.
>
> But the HTTP status text is a sequence of bytes, while the return value
> for statusText is a DOMString.  The conversion from one to the other needs
> to be defined.


If I may summarize:

(1) although RFC2616 prescribes the use of 8859-1 for the on-the-wire
representation of status text, this has not been followed in practice, and
indeed, arbitrary character encodings are being used when serializing the
reason status;

(2) xhr client implementations have two options for exposing status text:

   - do not interpret status text in terms of character encoding; rather,
   simply expose the byte string to the user-defined code and leave encoding
   determination up to the user-defined code;
   - do interpret status text encoding, and convert to a semantically well
   defined character string, possibly requiring sniffing the serialized byte
   sequence;

(3) in both of these options, it is possible to use DOMString to return the
results:

   - in the first case, using what I have called "hyde mode", the DOMString
   merely serves as an unsigned short[] for which the originally serialized
   byte sequence (of status text) is stuffed into the lower bytes (having no
   necessary relationship to a Unicode coded character sequence);
   - in the second case, using what I have called "jekyll mode", the
   DOMString is interpreted (as normal) as a UTF-16 encoded Unicode string
   (corresponding to a well-defined Unicode coded character sequence);

Is this a accurate summary?

I agree that if the first option above is chosen, then the inflate
algorithm is adequate. However, the specification text should make it
abundantly clear that the "hyde mode" flavor of DOMString is being
employed, and that the user defined code has the burden of decoding.

As a web-content author and user, I would prefer that option #2 is adopted;
or, if I were very particular, I would prefer that two accessors were
provided: one for obtaining the raw input bytes (e.g., as a BLOB) and
another for obtaining the client's best guess at a decoded Unicode string.
In this latter case, I could make the decision on which to use.

Overall, I could accept option #1 if the spec makes clear that "hyde mode"
applies.

G.

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Wed, Mar 28, 2012 at 4:48 AM, Julian Reschke wrote:

> On 2012-03-28 09:48, Glenn Adams wrote:
>
>> I'm not sure what you mean by citing ISO-8859-1 and UTF-8 in the same
>
> context. Please elaborate.
>>
>
> If you have UTF-8 on the wire and the client handles it as ISO-8859-1, the
> API user can extract the original octets from the string and re-decode from
> UTF-8. Of course that requires either heuristics or out-of-band information
> that this actually was UTF-8 in the first place.


The problem I have with this is now you have DOMString serving as a
container for an arbitrary byte string; i.e., no longer having any relation
to a UTF-16 code unit sequence. Naive uses of DOMString should be able to
assume it denotes UTF-16 encoded strings.

Any use of DOMString to serve as a holder for arbitrary binary data
(including inflating from UTF-8 bytes into 16-bit code units), should be
specifically marked as such. Since the user authored content will need to
know it is in fact not UTF-16 data.

Let's call these two modes jekyll and hyde. When the inflate algorithm's
input coding is not specified or known, then the output is a hyde mode
DOMString, which is in fact not a character string, but merely an unsigned
short[] array with no other semantics.

It is certainly possible to define reasonStatus in this fashion, but if
done this way, it should be made abundantly clear in the spec that this
usage of DOMString is of they hyde variety, which has the effect of placing
the burden of charset sniffing on the user defined code. This is certainly
a possible strategy for XHR client implementations to use in order to deal
with the mess of actual usage in the web (wherein the 8859 dictum was
ignored).

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Wed, Mar 28, 2012 at 3:50 AM, Anne van Kesteren  wrote:

> On Wed, 28 Mar 2012 08:52:25 +0100, Glenn Adams  wrote:
>
>> Well, that would define a specific, definite algorithm. Never mind that
>> it would introduce random bytes into DOMStrings that may or may not have
>> anything to do with character data.
>>
>
> That's false.
>

What is false? At present, the inflate algorithm does not make reference to
any character encoding, so it just treats the data as bytes; therefore, it
is *not* well defined when no character encoding is associated with the
input byte sequence.


> Using iso-8859-1 is ambiguous as it is a common alias for windows-1252
> which is definitely not what we want here.


I'm not sure what you mean by ambiguous. If users/servers mislabel content
as 8859-1 or if they insert non-8859-1 data into byte strings that are
defined to be 8859-1, then that is a usage problem, not a spec problem.

My point about introducing random bytes has to do with whether the inflate
algorithm is employed as is or in conjunction with a normative statement
about how to (semantically) interpret the input byte string (to the inflate
algorithm). If we declare (normatively, in the spec) that it is 8859-1 then
the algorithm and spec are now well defined. However, absent of declaring
the encoding of the input byte string, the inflate algorithm output is not
semantically known.

I am assuming here that neither the inflate algorithm nor the (http) client
is attempting to guess/sniff the encoding of the reason status string. Or
are you suggesting otherwise?

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Wed, Mar 28, 2012 at 2:33 AM, Anne van Kesteren  wrote:

> On Tue, 27 Mar 2012 22:23:15 +0100, Boris Zbarsky 
> wrote:
>
>> But the HTTP status text is a sequence of bytes, while the return value
>> for statusText is a DOMString.  The conversion from one to the other needs
>> to be defined.
>>
>
> Would using http://dvcs.w3.org/hg/xhr/raw-**file/tip/Overview.html#**
> inflate-a-byte-sequence-into-**a-domstringbe
>  sufficient or is there something in particular we should do?


Well, that would define a specific, definite algorithm. Never mind that it
would introduce random bytes into DOMStrings that may or may not have
anything to do with character data.

I personally think a better solution is simply to dictate that reason
status *always* be interpreted as ISO-8859-1, which would, in effect, make
the inflate algorithm well defined; i.e., no longer simply random bytes.

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Wed, Mar 28, 2012 at 1:33 AM, Julian Reschke wrote:

> On 2012-03-28 00:35, Glenn Adams wrote:
>
>>
>> On Tue, Mar 27, 2012 at 4:17 PM, Boris Zbarsky > <mailto:bzbar...@mit.edu>> wrote:
>>
>>On 3/27/12 2:46 PM, Glenn Adams wrote:
>>
>>Is this really a problem?
>>
>>
>>Yes.  We've run into bug reports in the past of sites sending some
>>pretty random bytes in the HTTP status text, then reading
>>.statusText from script.  If we want interop here, we need to define
>>the conversion.
>>
>>
>>HTTP defines the form and encoding of the status text
>>
>>
>>Except it doesn't, last I checked.  Has that changed?
>>
>>
>> RFC2616 states (on pages :
>>
>> Fielding, et al. Standards Track [Page 39]
>>
>>Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
>>
>> Fielding, et al. Standards Track [Page 40]
>>
>>Reason-Phrase  = *
>>
>> Fielding, et al. Standards Track [Page 15]
>>
>>The TEXT rule is only used for descriptive field contents and values
>>that are not intended to be interpreted by the message parser. Words
>>of *TEXT MAY contain characters from character sets other than ISO-
>>8859-1 [22] only when encoded according to the rules of RFC 2047
>>[14].
>>
>>TEXT   => but including LWS>
>>
>> This makes it pretty clear that Reason Phrase must use ISO-8859-1
>> (Latin1) unless it uses the encoded-word extension from RFC2047. If the
>> latter is used, then a charset must be designated.
>>
>> Given this, I don't see any spec bug (though there may be implementation
>> bugs in case the client side does not correctly implement the above HTTP
>> requirements).
>>
>
> It's time to stop citing RFC 2616. Please have a look at <
> http://greenbytes.de/tech/**webdav/draft-ietf-httpbis-p2-**
> semantics-19.html#rfc.section.**4<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.4>
> >.
>

Since 2616 is published and HTTPbis is not, I will go on citing it.


> Summary: HTTPbis does not attempt to define the character encoding
> anymore; if you use anything other than US-ASCII, you are on your own. RFC
> 2047 encoding never was used in practice, and has been removed.
>
> The right thing to do is the same as for header field values: use a
> US-ASCII compatible encoding that is most likely to work, and which is
> non-lossy, so a UTF-8 field value *can* be retrieved when needed.
>
> That encoding is ISO-8859-1.
>

I'm not sure what you mean by citing ISO-8859-1 and UTF-8 in the same
context. Please elaborate.


> (And HTTPBis doesn't talk about this because it defines octets on the
> wire, not an API).
>

If HTTPbis doesn't define the character encoding of bytes on the wire when
serializing reason status, then it leaves much to be desired.

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Tue, Mar 27, 2012 at 4:38 PM, Boris Zbarsky  wrote:

> On 3/27/12 3:36 PM, Boris Zbarsky wrote:
>
>> On 3/27/12 3:35 PM, Glenn Adams wrote:
>>
>>> The TEXT rule is only used for descriptive field contents and values
>>> that are not intended to be interpreted by the message parser. Words
>>> of *TEXT MAY contain characters from character sets other than ISO-
>>> 8859-1 [22] only when encoded according to the rules of RFC 2047
>>> [14].
>>>
>>
>> I believe that does not actually match server reality, unfortunately...
>>
>
> And one more thing.  Even the text you quoted does not define what happens
> if the rules from RFC 2047 are followed incorrectly (e.g. declaring a UTF-8
> encoding but then having byte sequences that are not valid UTF-8 in the
> data).  The behavior needs to actually be defined here for all values of
> the status text, whichever spec that happens in.


Since there are so may places in XHR, HTML5, etc., that interact with HTTP
semantics, it would be better to define this in one place for all uses, and
not attempt to redefine at every place where conversion to DOMString
occurs. DRY.

Re: [xhr] statusText is underdefined

[Glenn Adams]

On Tue, Mar 27, 2012 at 4:17 PM, Boris Zbarsky  wrote:

> On 3/27/12 2:46 PM, Glenn Adams wrote:
>
>> Is this really a problem?
>>
>
> Yes.  We've run into bug reports in the past of sites sending some pretty
> random bytes in the HTTP status text, then reading .statusText from script.
>  If we want interop here, we need to define the conversion.
>
>
>  HTTP defines the form and encoding of the status text
>>
>
> Except it doesn't, last I checked.  Has that changed?


RFC2616 states (on pages :

Fielding, et al. Standards Track [Page 39]


   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Fielding, et al. Standards Track [Page 40]

   Reason-Phrase  = *

Fielding, et al. Standards Track [Page 15]


   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than ISO-
   8859-1 [22] only when encoded according to the rules of RFC 2047
   [14].

   TEXT   = 


This makes it pretty clear that Reason Phrase must use ISO-8859-1 (Latin1)
unless it uses the encoded-word extension from RFC2047. If the latter is
used, then a charset must be designated.

Given this, I don't see any spec bug (though there may be implementation
bugs in case the client side does not correctly implement the above HTTP
requirements).

Re: [xhr] statusText is underdefined

[Glenn Adams]

Is this really a problem? HTTP defines the form and encoding of the status
text, and WebIDL/ES defines the form and encoding of DOMString. Adding an
explicit conversion definition seems redundant and overspecified. I would
argue the same for all other cases in the spec where it calls out an
explicit (and unnecessary) conversion.

On Tue, Mar 27, 2012 at 3:23 PM, Boris Zbarsky  wrote:

> The spec says:
>
>  Return the HTTP status text.
>
> But the HTTP status text is a sequence of bytes, while the return value
> for statusText is a DOMString.  The conversion from one to the other needs
> to be defined.
>
> -Boris
>
>

Re: informal survey - on spec philosophy

[Glenn Adams]

On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr. wrote:

> On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams  wrote:
> > It has been stated to me that, at least for "open web platform
> standards",
> > the following statement is true and is shared by the majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
> >
> > I happen to disagree with the truth of this, based on my personal
> experience
> > both with spec writing and with implementation/use of specs, but I would
> be
> > curious to see who agrees with this idea or not.
> >
> > The case in point is an instance of a possible ambiguity in a spec
> because a
> > particular assumption/convention is not documented; i.e., an assumption
> that
> > something isn't allowed even though it isn't explicitly disallowed.
> While I
> > agree it is, in general, impossible (or at least impractical) to document
> > all disallowances, I do believe it is important to document important
> > disallowances, particular when there are concerns raised about spec
> > ambiguity.
>
> The statement you quoted is more or less accurate.  Behavior that
> isn't specced is almost certain to not be interoperable.  If the spec
> is incomplete or unclear in some aspect, that's a spec bug, not an
> opportunity for implementations to make up their own behavior based on
> what the engineer thinks is reasonable at the time they're writing the
> code.
>

however, that is exactly what implementers do every day... especially those
not closely connected with the spec process

Re: informal survey - on spec philosophy

[Glenn Adams]

On Mon, Mar 26, 2012 at 4:23 PM, Kang-Hao (Kenny) Lu <
kennyl...@csail.mit.edu> wrote:

> (12/03/27 5:43), Glenn Adams wrote:
> > my position is that, unless somewhere it is documented what the
> convention
> > "associated with" means, that it is (1) ambiguous, and (2) can be
> > interpreted in any of the above four ways;
>
> This is still lacking context, but in general I agree with you.
>

The specific context this came up in is [1].

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299


> > this also goes to the issue of whether "if it is not documented in the
> spec
> > it is not allowed" applies; my position is that if the spec is ambiguous
> > (allows for multiple reasonable readings), then it is allowed (even
> though
> > that may not have been the author's intent);
>
> Agreed.
>
> (12/03/27 4:40), Glenn Adams wrote:
> > It has been stated to me that, at least for "open web platform
> > standards", the following statement is true and is shared by the
> > majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
>
> What context was this statement in? For the spec for API A, you can't
> really write a test that asserts the non-existence of API B of course.
>

 A WebApps spec editor made this assertion to me "if it isn't written in
the spec, it isn't allowed by the spec". I did (do) not agree. I wondered
what others think.

The specific context is how to interpret "associated with" and whether it
means one-to-one or not. Since the spec doesn't define "associated with", I
argue that it need not be interpreted as one-to-one. However, the editor
argued that if the spec doesn't say that it can be interpreted as
non-injective (not one-to-one), then this interpretation is not allowed.

Re: informal survey - on spec philosophy

[Glenn Adams]

On Mon, Mar 26, 2012 at 2:46 PM, Marcos Caceres  wrote:
>
>  On Monday, 26 March 2012 at 21:40, Glenn Adams wrote:
>
> > It has been stated to me that, at least for "open web platform
> standards", the following statement is true and is shared by the majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
> Can you provide some examples of what you mean? This seems a little out of
> the blue?
>

the spec phrase "associated with" can be interpreted as any of the
following relations [1]:

   - injective and surjective (one-to-one and onto)
   - injective and non-surjective (one-to-one but not onto)
   - non-injective and surjective (not one-to-one but onto)
   - non-injective and non-surjective (not one-to-one and not onto)

[1] http://en.wikipedia.org/wiki/Bijection,_injection_and_surjection

it has been claimed that "associated with" means at least injective and
perhaps also surjective, and that since the spec does not say it can be
non-injective, then the last two could not apply;

my position is that, unless somewhere it is documented what the convention
"associated with" means, that it is (1) ambiguous, and (2) can be
interpreted in any of the above four ways;

this also goes to the issue of whether "if it is not documented in the spec
it is not allowed" applies; my position is that if the spec is ambiguous
(allows for multiple reasonable readings), then it is allowed (even though
that may not have been the author's intent);


> >
> > I happen to disagree with the truth of this, based on my personal
> experience both with spec writing and with implementation/use of specs, but
> I would be curious to see who agrees with this idea or not.
> >
> > The case in point is an instance of a possible ambiguity in a spec
> because a particular assumption/convention is not documented;
> Which one?
>

see above


> > i.e., an assumption that something isn't allowed even though it isn't
> explicitly disallowed. While I agree it is, in general, impossible (or at
> least impractical) to document all disallowances, I do believe it is
> important to document important disallowances, particular when there are
> concerns raised about spec ambiguity.
> >
>
>  I guess it's a case by case thing. But generally, if the spec is written
> with a "not in spec, not allowed" state machine, then it would hold.
>

there are two issues here:

(1) whether the spec is ambiguous or not (permits multiple
interpretations), and
(2) whether there is an unwritten convention (if the spec doesn't say it
then it is not allowed) that applies or not

my position is that ambiguities should be avoided wherever possible and
that important conventions should be documented; further, i'm not sure I
would agree with a convention of "if the spec doesn't say it then it is not
allowed"; or at least, that is the point of this thread, to see what others
think...

informal survey - on spec philosophy

[Glenn Adams]

It has been stated to me that, at least for "open web platform standards",
the following statement is true and is shared by the majority:

"if it isn't written in the spec, it isn't allowed by the spec"

I happen to disagree with the truth of this, based on my personal
experience both with spec writing and with implementation/use of specs, but
I would be curious to see who agrees with this idea or not.

The case in point is an instance of a possible ambiguity in a spec because
a particular assumption/convention is not documented; i.e., an assumption
that something isn't allowed even though it isn't explicitly disallowed.
While I agree it is, in general, impossible (or at least impractical) to
document all disallowances, I do believe it is important to document
important disallowances, particular when there are concerns raised about
spec ambiguity.

Regards,
Glenn

Re: WebSockets -- only TCP?

[Glenn Adams]

no

On Mon, Mar 19, 2012 at 1:09 AM, Rick van Rein  wrote:

> Hello,
>
> > See PeerConnection in http://dev.w3.org/2011/webrtc/editor/webrtc.html
>
> Ah, I was looking in the wrong place then :)
>
> Is this considered as part of the HTML5 specification?
>

Re: WebSockets -- only TCP?

[Glenn Adams]

RFC 6455 defines WSP as a TCP protocol [1]

[1] http://tools.ietf.org/html/rfc6455#section-1.5

at present the WebSocket API is nothing more than a thin layer over WSP,
and references WSP for all protocol bindings;

there is no "discarding" of UDP involved; it simply is/was not a
requirement driving WSP;

if someone defines a new flavor of WSP in the future based on UDP, e.g.,
WSPU, then the WebSocket API could be updated to make reference to it;

in conclusion, I don't see any cause to change the WebSocket API draft to
explicitly suggest use of an alternative protocol (to WSP) since none
exists at this time;

On Thu, Mar 15, 2012 at 5:28 AM, Rick van Rein  wrote:

> Hello,
>
> I would like to comment on the current (20120313) WebSockets
> specification.
>
> The text sounds to me like it implicitly assumes that all
> protocols are run over TCP.  It could be said that the choice
> of URL makes it sufficiently general to include UDP (and
> possibly SCTP), but the usage of terms like connecting sends
> a hint to implementers that support of TCP would suffice.
>
> If the intention is to create a TCP-only WebSocket, then I
> think this should be made explicit.  And if UDP would also
> be supported, then a remark around connection states that
> some apply only to connection-oriented URL protocols would
> send a clearer message to implementers.
>
> I do think UDP is too important to discard from WebSockets;
> among the things we can do with current technology (Flash or
> Java) is a softphone running in a browser; in a TCP-only
> HTML5 environment with deprecated support for these
> technologies such options would have no standing ground.
>
>
> I hope this is helpful feedback.
>
>
> Best wishes,
>
> Rick van Rein
> OpenFortress
>
>
>

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Adams]

On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams  wrote:

>
> HTML
>
> A conforming user 
> agent<http://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation> 
> MUST
> support at least the subset of the functionality defined in HTML that this
> specification relies upon; in particular, it must support event 
> loops<http://dev.w3.org/2006/webapi/FileAPI/#event-loops>
>  and event handler 
> attributes<http://dev.w3.org/2006/webapi/FileAPI/#event-handler-attributes>.
> [HTML <http://dev.w3.org/2006/webapi/FileAPI/#HTML>]
>
Ignore the above paragraph.

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Adams]

On Wed, Feb 29, 2012 at 2:58 PM, Arun Ranganathan
wrote:

> On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan <
> aranganat...@mozilla.com> wrote:
>
>  On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan <
>> aranganat...@mozilla.com> wrote:
>>
>> Should the actual UTF-8 encoding algorithm be specified by HTML?
>>
>> I don't know, since I think that Unicode to UTF-8 is pretty common.
>> Might help if it was part of the common infrastructure.
>>
>
> what needs to be specified that isn't already found in Unicode [1], clause
> D92, p92ff?
>
> [1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf
>
>
> I think that gets us by.  Do you think we need a reference in FileAPI?  Or
> can we merely say to encode as UTF-8 and leave it to implementations (a
> reasonable assumption IMHO).
>

I think you should have a reference. You could either use the following, as
does HTML5:

[RFC3629]UTF-8, a transformation format of ISO
10646,
F. Yergeau. IETF.

or you could modify the language in Section 4 Terminology and Algorithms to
read:

The terms and algorithms *UTF-8*, , , document, unloading
document cleanup steps, event handler attributes, event handler event type,
origin, same origin, event loops, task, task source, URL, and queue a task are
defined by the HTML specification
[HTML
].


HTML

A conforming user
agent
MUST
support at least the subset of the functionality defined in HTML that this
specification relies upon; in particular, it must support event
loops
 and event handler
attributes.
[HTML ]

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Adams]

On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan
wrote:

> On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan <
> aranganat...@mozilla.com> wrote:
>
> Should the actual UTF-8 encoding algorithm be specified by HTML?
>
> I don't know, since I think that Unicode to UTF-8 is pretty common.  Might
> help if it was part of the common infrastructure.
>

what needs to be specified that isn't already found in Unicode [1], clause
D92, p92ff?

[1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf

Re: IME API Use cases editorial feedback

[Glenn Adams]

On Wed, Feb 29, 2012 at 2:59 AM, Kang-Hao (Kenny) Lu <
kennyl...@csail.mit.edu> wrote:

> http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html
>
> SUN Haitao found the description of the Traditional Chinese IME used as
> an example in this use cases document somewhat inaccurate.
>
> 3.1.2 Radical composer
> __
>
>  # typing ‘o’ produces ‘人’ on a Traditional-Chinese (or Bopomofo)
>  # keyboard
>
> s/Bopomofo/Changjie/
>

I would suggest "Cangjie" as the preferred spelling for 倉頡 (仓颉) [1].

[1] http://en.wikipedia.org/wiki/Cangjie_input_method


> (It's not clear to me if Changjie radicals are phonetic but I am totally
> ignorant on this subject)
>

they are not phonetic, nor are they semantic; they are geometric only (as
graphical mnemonics)



> 3.2 Converter
> _
>
>  # Bopomofo characters ‘人弓’ matches Traditional-Chinese
>  # ideographic characters ‘乞’, ‘亿’, ‘亇’, etc.
>
> s/Bopomofo characters/Changjie components/
>

s/Changjie/Cangjie/


> Cheers,
> Kenny
>
>
>

Re: [webcomponents] Considering declarative event handlers

[Glenn Adams]

On Tue, Feb 7, 2012 at 12:41 PM, Dimitri Glazkov wrote:

> To make Web Components more usable, I would like to consider providing
> a way to declare event handlers in markup. As I look over the use
> cases and try to implement them using the proposed syntax
> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html),
> a pattern emerges, where a bunch of event handlers is declared and
> registered early in the lifecycle of the custom elements
> (
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/samples/entry-helper.html
> ,
> http://dglazkov.github.com/Tabs/tabs-control.js as rough examples).
>

Is there a reason not to use (modifying as required) XML Events [1] for
this purpose?

[1] http://www.w3.org/TR/2003/REC-xml-events-20031014/

Re: CfC by 02-14: Add IME API to the charter

[Glenn Adams]

thanks, i was just checking; i'll defer to Addison and the editor of the
proposed work to handle the details

On Wed, Feb 8, 2012 at 9:02 AM, Michael[tm] Smith  wrote:

> Hi Glenn,
>
> > @2012-02-08 08:33 -0700:
> > will there be liaison/participation with I18N Core WG on this work?
>
> I've already given Richard Ishida and Felix Sasaki a heads-up about it. I
> believe Richard is planning to propose an agenda item for it on the i18n WG
> call today. But anyway certainly there shall be active liaise-ing with i18n
> folk on this API. If you believe we need to capture that in the charter
> then I can work with the chairs to make sure we do that.
>
>  --Mike
>
> --
> Michael[tm] Smith
> http://people.w3.org/mike/+
>

Re: CfC by 02-14: Add IME API to the charter

[Glenn Adams]

will there be liaison/participation with I18N Core WG on this work?

On Wed, Feb 8, 2012 at 5:29 AM, Charles McCathieNevile wrote:

> Hi,
>
> thanks to Mike and the Google guys, we have http://dvcs.w3.org/hg/ime-api/
> **raw-file/default/use-cases/**Overview.htmlwhich
>  explains what an IME API would do and why it would be useful. I
> believe we have editors but it doesn't name a test facilitator (don't blame
> me, Art chose that as the name ;) ) and we need one. I am assuming that
> will be forthcoming, so this is a formal call for Consensus to add this
> item to the charter.
>
> Silence will be considered assent, positive response is preferred, and the
> deadline is the end of Tuesday 14th February.
>
> cheers
>
> Chaals
>
> --
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>je parle français -- hablo español -- jeg kan litt norsk
> http://my.opera.com/chaals   Try Opera: http://www.opera.com
>
>

Re: CfC: Charter addition for Fullscreen API

[Glenn Adams]

On Thu, Feb 2, 2012 at 4:14 PM, Anne van Kesteren  wrote:

> On Fri, 03 Feb 2012 00:09:44 +0100, Glenn Adams  wrote:
>
>> On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren 
>> wrote:
>>
>>> I'm fine with publishing this through WebApps.
>>>
>>
>> is there any reason this should be done as part of CSSOM View? i notice a
>> "to do" listed at [1] as:
>>
>>   - CSSOM should have a mechanism for taking elements full-screen
>>
>> [1] http://wiki.csswg.org/spec/**cssom <http://wiki.csswg.org/spec/cssom>
>>
>
> That was mostly because it was tangentially related (and at some point
> suggested to be put there), but now it's drafted as a separate document I
> think it's fine to keep it as such.


ok, sounds good

Re: CfC: Charter addition for Fullscreen API

[Glenn Adams]

On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren  wrote:

> On Tue, 31 Jan 2012 18:07:39 +0100, Arthur Barstow 
> wrote:
>
>> On 1/31/12 11:04 AM, ext Robin Berjon wrote:
>>
>>> We have a draft
>>> http://dvcs.w3.org/hg/**fullscreen/raw-file/tip/**Overview.html
>>> I'm pretty sure that I've seen implementer interest, and it's very
>>> obvious that there's a lot of developer interest in it. My understanding is
>>> that it has an editor.
>>>
>>
>> It would be good to get confirmation from Anne and/or Tantek.
>>
>
> I'm fine with publishing this through WebApps.


is there any reason this should be done as part of CSSOM View? i notice a
"to do" listed at [1] as:

   - CSSOM should have a mechanism for taking elements full-screen

[1] http://wiki.csswg.org/spec/cssom

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 1:26 PM, Ian Hickson  wrote:

> On Tue, 24 Jan 2012, Glenn Adams wrote:
> >
> > Ian, I agree with the sentiment of your response ("take DOM4 right now
> and
> > publish it as a REC"). And, were it not for the W3C Process Document, we
> > might do just that. However, for the time being, we need to work within
> the
> > process document.
>
> Actually, no, we don't. We're sentient beings, our adherence to
> bureaucratic protocols is entirely voluntary.
>

Right. And last time I checked this is a W3C mailing list, a W3C group, and
W3C documents under discussion. So presumably we sentient beings have at
least implicitly signed up to the W3C Process (whether we agree with it or
not). Let's not continue to belabor this thread though since, as you say,
its beside the point. :)

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

DOM2 was not created for the purpose of reflecting the behavior in popular
implementations. So it would be misleading to use this rationale. I would
suggest the more neutral language I proposed above:

"Although DOM Level 2 continues to be subject to Errata
Management<http://www.w3.org/2005/10/Process-20051014/tr.html#errata>,
it is no longer being actively maintained. Content authors and implementers
are encouraged to consider the use of newer formulations of the Document
Object Model, including DOM4 <http://www.w3.org/TR/dom/>, which is
currently in process for Advancing a Technical Report to
Recommendation<http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance>
."

I believe this avoids any misreadings and has the intended effect of
warning authors/implementers about the status of DOM2 and its newer
formulation in progress.

On Tue, Jan 24, 2012 at 1:21 PM, Jonas Sicking  wrote:

> I think the point that is most important to me to capture is that DOM2
> no longer reflects the behavior in many browsers.
>
> So how about:
>
> DOM2 is no longer updated and doesn't in all cases reflect behavior in
> popular implementations. DOM4 is the latest actively maintained and
> updated version. 
>
> / Jonas
>
> 2012/1/24 Ojan Vafai :
> > Can we just compromise on the language here? I don't think we'll find
> > agreement on the proper way to do spec work.
> >
> > How about: "DOM2 is no longer updated. DOM4 is the latest actively
> > maintained version. "
> >
> >
> > On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams  wrote:
> >>
> >> I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same
> >> as saying DOM2 is a WIP. This is because the former can be read as
> saying
> >> that the normative content of DOM2 is now replaced with DOM4.
> >>
> >> I'm not sure what you mean by "[DOM2] is a work on which progress has
> >> stopped". DOM2 is a REC, and is only subject to errata [1] and
> rescinding
> >> [2].
> >>
> >> [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify
> >> [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind
> >>
> >> I'm not sure where the proposed obsolescence message falls in terms of
> [1]
> >> or [2]. Perhaps you could clarify, since presumably the process document
> >> will apply to any proposed change.
> >>
> >> On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger  wrote:
> >>>
> >>> On 01/24/2012 08:33 PM, Glenn Adams wrote:
> >>>>
> >>>> The problem is that the proposal (as I understand it) is to insert
> >>>> something like:
> >>>>
> >>>> "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
> >>>>
> >>>> This addition is tantamount (by the reading of some) to demoting the
> >>>> status
> >>>> of DOM2 to "a work in progress".
> >>>
> >>>
> >>> Not at all; it's a work on which progress has stopped long ago.
> >>>
> >>
> >
>

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

Ian, I agree with the sentiment of your response ("take DOM4 right now and
publish it as a REC"). And, were it not for the W3C Process Document, we
might do just that. However, for the time being, we need to work within the
process document. The best way to do that is attempt to (as rapidly as
possible) obtain consensus on publishing DOM4 as a LC then quickly progress
to CR. I personally (and the member I represent) will do whatever I (we)
can to assist in that process. And the same applies for the other WIP DOM
related specs.

On Tue, Jan 24, 2012 at 1:15 PM, Ian Hickson  wrote:

> On Tue, 24 Jan 2012, Glenn Adams wrote:
> > On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai  wrote:
> > >
> > > You keep saying this throughout this thread without pointing to
> > > specifics. It's impossible to argue with broad, sweeping
> > > generalizations like this. So far, you have yet to point to one
> > > concrete organization/statute that cares about REC status.
> >
> > Ojan, apparently you are not familiar with international or national
> > standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I
> > could give you a list of hundreds if you wish, all having encoded such
> > rules into their formal processes.
>
> I've no problem with providing stale snapshots for use by standards
> organisations and governments stuck with outdated models. That's fine.
> Nobody is saying that we should remove DOM2 altogether. Indeed, I've been
> arguing we should publish snapshots _more often_. I say we take DOM4 right
> now and publish it as a REC, and then do that every 6 months. That's the
> best way to serve organisations that need this artificial "stability".
>
> The point is to make sure that people reading the stale documents know
> that that is what they are doing. That's why the proposal is merely to
> have a warning on the stale documents, not remove them altogether.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 1:12 PM, Boris Zbarsky  wrote:

> On 1/24/12 8:58 PM, Glenn Adams wrote:
>
>>
>> 2012/1/24 Ojan Vafai mailto:o...@chromium.org>>
>>
>>
>>Can we just compromise on the language here? I don't think we'll
>>find agreement on the proper way to do spec work.
>>
>>How about: "DOM2 is no longer updated. DOM4 is the latest actively
>>maintained version. "
>>
>>
>> That doesn't really work for me. What would work for me is something like:
>>
>> "Although DOM Level 2 continues to be subject to Errata Management
>>
>
> Except it's not.  As far as I know, errata haven't been published for
> close to a decade now, and there are no plans to publish any.  This in
> spite of known things that need errata.
>

As long as the W3C Process Document [1] applies, DOM2 is "subject" to
Errata Management until such a time as it is formally Rescinded. It matters
not whether there are any plans to publish errata or not.

[1] http://www.w3.org/2005/10/Process-20051014/