W3C home > Mailing lists > Public > public-awwsw@w3.org > October 2011

Fwd: Re: Friction and cross pollination

From: Jonathan Rees <jar@creativecommons.org>
Date: Sun, 16 Oct 2011 09:40:11 -0400
Message-ID: <CACHXnaoV_w95LxaGCcDa8zT=QaxpOniq5u2f4N3RLrfg3E-AgQ@mail.gmail.com>
To: AWWSW TF <public-awwsw@w3.org>
---------- Forwarded message ----------
From: Larry Masinter <masinter@adobe.com>
Date: Sat, Oct 15, 2011 at 4:05 PM
Subject: RE: Re: Friction and cross pollination
To: "Michael.Champion@microsoft.com" <Michael.Champion@microsoft.com>
Cc: Mike Champion <Michael.Champion@microsoft.com>, Norm Walsh
<ndw@nwalsh.com>, Noah Mendelsohn <nrm@arcanedomain.com>,
"www-tag@w3.org" <www-tag@w3.org>

Michael, to respond to your comment about creation of task forces:

 First, the TAG can't really force the creation of a task force, it's
a suggestion that requires commitment on the part of multiple parties.
I see absolutely no reason why the TAG should not encourage them when
they seem appropriate. If you're saying "don't create a task force
until there are people who volunteer to participate", well, I thought
we weren't, and maybe it's just the call for participation has been
unclear about the expected outcome.

The TAG doesn't have the bandwidth to address all of the architectural
issues, and calling for other groups to be formed by the W3C is an
appropriate role for the TAG. I reject the notion that "if you want it
done you have to do it yourself".

The "task forces" we've called for focus on situations where there are
multiple specifications which seem incompatible and where even the
analysis of workflows going from one to another aren't specified --
that seems like a good fodder for a task force.

 What I'd looking for is a clear analysis of what the various use
cases might be, of what the compatibility problems are, what
workarounds may or may not apply, appropriate future directions.  Even
if neither "side" budges a single bit about changing any specification
whatsoever, it is still possible to make much better progress on at
least understanding what the compatibility problems really are and
what difficulties they cause.

If along the way, there are some apparent changes to one or the other,
or some additional infrastructure or developments that would improve
the situation, that's great. But it's not criterial for success.

In all of the cases where we have called for "Task forces" that I can
think of, it is a situation where multiple groups or a single group
are creating overlapping and incompatible specifications, usually
where a "new" specification breaks an older one, but in a way where
the breakage seems like it could be reduced, minimized, resolved, or
that cross-workflows at least need to be analyzed and the difficulties
described

A specific, dedicated task force of responsible people who are
actually interested in making progress -- seems perfectly appropriate.
Your counter-proposal -- waiting until there is a ground-swell of
interest in getting together -- is really giving up responsibility.
There are always skeptics. What are they skeptical about? That we
could even understand the workflows? That we could even document the
incompatibilities?

Frankly, I don't see too many skeptics, what I see are people who just
think the other side is going to wither up and go away, and that the
task force gives attention to problems they'd just as soon sweep under
the table.

I think this goes for XML/XHTML/HTML, microdata/RDFa, and that we
might need additional task forces, e.g., to look at canvas/SVG/CSS
overlaps and incompatibilities.

IMHO

Larry
--
http://larry.masinter.net





-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Noah Mendelsohn
Sent: Friday, October 14, 2011 11:31 AM
To: www-tag@w3.org
Cc: Mike Champion; Norm Walsh
Subject: Fwd: Re: Friction and cross pollination

Michael Champion posted this to the public-html-xml mailing list, but
it includes some suggestions directed to the TAG, so I'm relaying it
here.

This is part of a larger thread focused mainly on what the draft
report from the XML/HTML working group should say. Suggestion:

* Discussion of the content of the report should remain on public-html-xml

* Discussion of the general issue of having the TAG either create task
forces, or suggest that the W3C create them, should be held mainly
here on www-tag@w3.org.

OK? Thank you.

Noah

-------- Original Message --------
Subject: Re: Friction and cross pollination
Resent-Date: Fri, 14 Oct 2011 16:22:59 +0000
Resent-From: public-html-xml@w3.org
Date: Fri, 14 Oct 2011 16:22:27 +0000
From: Michael Champion <Michael.Champion@microsoft.com>
To: Robin Berjon <robin@berjon.com>, Henri Sivonen <hsivonen@iki.fi>
CC: public-html-xml@w3.org <public-html-xml@w3.org>

> All of these paths are work for other groups, new (community) groups,
>or even just open source projects.

Exactly.  Let's declare victory on this task force report, and suggest
that people who have been inspired by the discussions here but
couldn't build consensus for their additional ideas take them to
Community Groups or some other appropriate venue.

Editorializing a bit Š I think it's time to retire the pattern of the
TAG causing the creation of Task Forces to dig deep into topics that
interest them but they don't have the bandwidth to pursue.  Instead,
those people in the TAG or Team or wider community who see an unmet
need or envision a better solution should propose a community group,
see if there is critical mass to explore the idea, and if the group
comes up with a compelling solution THEN propose it to a WG to
standardize.  That will reduce the number of as-yet unsolvable
problems that get put into TF or WG charters while giving the people
with the vision and determination to solve them anyway a place to do
so (or not) unimpeded by the skeptics.


On 10/14/11 2:03 AM, "Robin Berjon" <robin@berjon.com> wrote:

>On Oct 13, 2011, at 19:01 , Henri Sivonen wrote:
>> On Tue, Oct 4, 2011 at 2:34 PM, Robin Berjon <robin@berjon.com> wrote:
>>> A suggested list of such smaller projects, which may or may not
>>>proliferate best in a standards setting, could for instance include:
>>
>> I'm uncomfortable with naming smaller projects that the TF hasn't
>> discussed previously when the Report is almost ready to be published.
>
>They are really just meant to be suggestions, definitely not endorsements.
>
>>>    € Defining an XSLT and XQuery serialisation for polyglot HTML.
>>>Usage: make it trivial to produce it with a regular XML tool chain.
>>>[ed. I thought that this had been done, but I can't seem to find it
>>>anywhere]
>>
>> I think it makes sense to have a new HTML5-aware HTML output method
>> for XSLT, but I think making it polyglot would be an unfortunate
>> distraction. You can't serialize the text content of HTML script and
>> style element polyglottally in the general case, but it would be
>> silly not to support the output of text content of HTML script and
>> style elements when the text content can be serialized as either HTML
>> or as X(HT)ML.
>
>Sure, I certainly don't think that it's worth trying too hard. But HTML
>output can be improved, and polyglot is likely a good source of
>inspiration.
>
>>>    € Help define an improved, more interoperable, and more usable
>>>version of DOM level 3 XPath for use from Javascript inside an HTML
>>>document. Usage: a number of queries (e.g. for text nodes, or certain
>>>axes) are impossible to achieve with the Selectors API, but using DOM
>>>level 3 XPath is unwieldy at best.
>>
>> How would a new API be more interoperable than the API that multiple
>> vendors already support? Also, big rathole warning about XPath
>> versions.
>
>See the discussion on WebApps about how consecutive text nodes are
>returned.
>
>>>    € CSS Fragment IDs based on XPointer as described in
>>>http://simonstl.com/articles/cssFragID.html. Usage: links that target
>>>fragments more powerfully, in a manner that browsers understand
>>>(http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/
>>>is a good example).
>>
>> Seems out of scope for this TF.
>
>[several times]
>
>All of these ideas are completely out of scope for this TF: we do not
>have the remit to produce a Rec-track document anyway. All of these
>paths are work for other groups, new (community) groups, or even just
>open source projects.
>
>--
>Robin Berjon - http://berjon.com/ - @robinberjon
>
>
>
Received on Sunday, 16 October 2011 13:40:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 October 2011 13:40:40 GMT