On 12/02/2014 06:55 AM, cha...@yandex-team.ru wrote:
TL;DR: Administrative details from the W3C Webapps cochair
responsible for URL in that group. Relevant in practice is a request
to minimise channels of communication to simplify spec archaeology,
and especially to prefer public-webapps over www-archive, but I don't
see there is any reason this WorkMode cannot be used.
TL;DR: the Invited Expert Agreement and public statements regarding the
contents of private Member Agreements is an obstacle; as are the lack of
substantive technical feedback on the public-webapps list.
02.12.2014, 04:19, "Sam Ruby" <ru...@intertwingly.net>:
On 11/18/2014 03:18 PM, Sam Ruby wrote:
Meanwhile, I'm working to integrate the following first into the
WHATWG version of the spec, and then through the WebApps
process:
http://intertwingly.net/projects/pegurl/url.html
Integration is proceeding, current results can be seen here:
https://specs.webplatform.org/url/webspecs/develop/
It is no longer clear to me what "through the WebApps process"
means. In an attempt to help define such, I'm making a proposal:
https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface
At this point, I'm looking for general feedback. I'm particularly
interested in things I may have missed.
A bunch of comments about how to work with a W3C group:
Participation and Communication… In W3C there is a general desire to
track contributions, and ensure that contributors have made patent
commitments. When discussion is managed through the W3C working
group, the chairs and staff contact take responsibility for this, in
conjunction with editors. If the editor wants to use other sources,
then we ask the editor to take responsibility for tracking those
sources. The normal approach is to request that contributors join the
Working Group, either as invited experts or because they represent a
member organisation. In many cases, contributors are already
represented in webapps - for instance while Anne van Kesteren isn't
personally a member, his employer is, and there is therefore a
commitment from them.
Examples of obstacles:
1) The no «Branching» language in the Invited Expert agreement:
http://www.w3.org/Consortium/Legal/2007/06-invited-expert
2) Public assertions that the Member agreements limit ways that specs
can be used to ways permitted by the W3C Document license. Example:
http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0166.html
I plan to work closely with W3C Legal to address both of these issues.
While webapps generally prefers conversations to be on the webapps
list (because it makes it easier to do the archaeology in a decade or
so if someone needs to), there is no formal ban on using other
sources. However, I would ask that you request comments on publicly
archived lists, and specifically that you strongly prefer
public-webapps@w3.org (which is a list designated for technical
discussion whose subscribers include W3C members who expect to
discuss work items in the scope of the webapps group, such as the URL
spec) to www-archive (which is just a place to give a public anchor
to random email - the subscription list is completely random and
likely not to include many interested W3C members).
Recent posts by David Walp, Jonas Sicking and Domenic Denicola give me
some hope that there can be meaningful technical discussion on this
list. That being said, this is an ongoing concern that needs to be
addressed.
The TR Process… The WHATWG document is not a "Public Working Draft"
in the sense of the W3C Process (which has implications for e.g.
patent policy). Regularly publishing a Public Working Draft to
w3.org/TR is part of what makes the patent policy work, since
commitments are bound to various stages including the latest Public
Working Draft (i.e. TR version, not editors' draft) before someone
left the group [wds]. Those snapshots are required to be hosted by
W3C and to meet the team's requirements, as determined by the Team
from time to time. If there is an issue there, let's deal with it
when we see it.
What is the hold-up for publishing a Public Working Draft? Can I ask
that you respond to the following email?
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html
Let me know what I need to do.
Webapps still generally works under the 2005 version of the Process -
but we could change this document to the 2014 process. The only
really noticeable difference will be that there is formally no "Last
Call", and the final Patent Exclusion opportunity is instead for the
draft published as Candidate Recommendation. (In other words, you
need to be pretty bureaucratically-minded to notice a difference).
Lets update to 2014 now. Its only a matter of time before not updating
won't be an option any more.
Documents published by W3C are published under whatever license W3C
decides. The Webapps charter explicitly calls out the URL spec for
publishing under the CC-BY license [chart], so that is what I would
expect for all snapshots.
I'm proposing that we revisit this, but meanwhile I acknowledge that per
the charter that's outside of the control of the Webapps WG.
For normative references, at least until Last Call or CR (depending
on whether you use the modern Process) I don't think we need to care
a huge amount. When we do get there, the policy for publishing at W3C
will determine what we can do in a W3C publication - although we
should note that there is a lot of discussion about references that
fails to take reality into account,and many specs have "normative
references" that are actually unusable normatively. My *personal*
sense is that a lot more references should be informative, admitting
the state of the universe as it is rather than as we wish it were.
But I'm inclined to cross that when we get there.
WFM.
Editors Editors of W3C specs are required [eds] to be members of the
Working Group publishing the spec. Webapps is pretty liberal about
appointing editors - the principal criteria are "you are in the group
and volunteer to do work".
Again, I see the principle obstacle to this being the Invited Expert
agreement and public statements that have been made about private Member
agreements.
Patent Policy As I read the invited expert agreement [iea] it uses
"branching" (quoted - french-style) as an example of "creating
derivative works that include the Invited Expert's contributions when
those derivative works are likely to cause confusion about the status
of the W3C work or create risks of non-interoperability with a W3C
Recommendation" (see para. 3), rather than explicitly forbidding
particular styles of collaboration agreed to by the W3C working group
consistent with the process. I will follow up with W3C legal, but
rather than a real problem this seems to be where a rhetorical effort
to create difference might draw inspiration.
I also plan to follow up with W3C Legal. Lets do so together.
I don't know where somebody read a restriction on something like the
workmode into the member agreement - I cannot see anything there
which supports such a reading.
W3C's position on forking has been consistent and controversial. My
primary concern at this point is that it has become an obstacle to
getting people to join the WebApps Working Group, and therefore an
obstacle to obtaining the necessary patent commitments.
Consensus
Webapps has URL in its list of deliverables [chart], so doesn't need
more consensus to do work on it. We do need it for publishing drafts,
and for transition requests, etc.
[eds] http://www.w3.org/2014/Process-20140801/#general-requirements (the same
text is in the 2005 document)
[chart] http://www.w3.org/2014/06/webapps-charter.html#deliverables
[wds] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-resign
[iea] http://www.w3.org/Consortium/Legal/2014/08-invited-expert.html
WFM.
Pull requests welcome!
Once discussion dies down, I'll try go get agreement between the URL
editors, the WebApps co-chairs and W3C Legal. If/when that is complete,
this will go to W3C Management and whatever the WHATWG equivalent would be.
- Sam Ruby
