RE: Friction and cross pollination

We should definitely make sure that the call for participation in a task force be clear that we're looking for people who are interested in working to improve the situation for which the task force was formed to address. The fact that there are others who aren't interested in the problem shouldn't slow them down too much.  

I'm not looking for a boat anchor on the evolution of HTML, just a navigation chart of the surroundings.   I don't understand the "community-specific" vs. "global architecture" distinction. The task force wasn't asked to solve "global architecture", but had what I thought was a specific charter.  Unlike a community group, which to some extent has freedom to go wherever its member want to go, and which might continue as long as there is interest and progress to be made, a "task force" is constituted to address a specific issue or problem, and be done.   

Community groups seem like just the wrong thing for the situations.

You say " people expressed a lot of passion about how a better HTML-XML alignment could solve *their* use cases" but I'm missing where in the report these use cases are documented and the difficulties from lack of HTML-XML alignment explained.  Did I not read it carefully enough? 

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



-----Original Message-----
From: Michael Champion [mailto:Michael.Champion@microsoft.com] 
Sent: Monday, October 17, 2011 1:25 PM
To: Noah Mendelsohn; Larry Masinter
Cc: ndw@nwalsh.com; www-tag@w3.org
Subject: Re: Friction and cross pollination

I acknowledge that "it's time to retire the pattern…" is an overstatement, meant mostly to suggest that the HTML-XML TF declare victory and move some outstanding questions to Community Groups.

This mini-rant was inspired by discussions in the HTML-XML TF where people expressed a lot of passion about how a better HTML-XML alignment could solve *their* use cases, and they're clearly frustrated by the disinterest on the part of those who have been dealing with XML - HTML co-existence for 10-15 years and have more or less lost interest in the problem.  I feel for both sides -- some are seeing a vision that lots of us shared back in the day and they still want to work to make it real; others believe that much of the world has moved on and have largely adopted JSON for data and HTML for text, and don't see the value of pursuing a unification.

For the HTML-XML situation, there are probably profiles, best practices, APIs, etc. that people could work on together  that could address some of the use cases, without trying to "fix" XML (which is largely done and burned into silicon) or add a boat anchor on the evolution of HTML.
That seems more suited to a community-specific approach than a global architecture approach to me.

I do suspect the same thing applies to the RDFa/Microdata and canvas/SVG/CSS situations, but that's getting into areas I'm not really up to speed on and don't wish to debate with the TAG.  

Thanks,
Michael Champion

On 10/15/11 1:21 PM, "Noah Mendelsohn" <nrm@arcanedomain.com> wrote:

>Without commenting on the merits of either Mike's or Larry's points, it 
>may be worth observing that the two most recent and visible "task 
>forces"
>instigate by the TAG are somewhat different in history and organization:
>
>* The HTML/XML task force came into being as essentially an offshoot of 
>the TAG. We had been studying the issue, had some (perhaps misplaced) 
>optimism that getting the right mix of people together would yield 
>insight not only into requirements and use cases (it did), but also 
>into changes to specifications that might be suggested as input to the 
>pertinent working groups (so far, not much good to report on that 
>part). Anyway, Norm was kind enough to volunteer to pull it together, 
>and it is proceeding toward finalizing a report.
>
>* With respect to the perceived overlap between RDFa and Microdata, the 
>TAG did two things: 1) it opened bugs against the pertinent draft 
>specifications and 2) it suggested to the W3C that the W3C might form a 
>task force. As I understand it, the W3C has responded by proposing that 
>an initial round of analysis be done by a group hosted in the SWIG.
>
>For what it's worth, I would very much like to have the option to 
>continue to use at least the first model from time to time. There are 
>many things the TAG is called upon to figure out where the 
>elected/appointed membership of the TAG doesn't have the needed skills. 
>Being able to call upon those who would volunteer their time is very 
>helpful.
>
>As to the second model, in which we suggest to the W3C the formation of 
>a task force, I don't see the value of precluding ever doing such a 
>thing, though I read Mike as suggesting that we should be careful, 
>perhaps more careful, to do so only when we are optimistic that the 
>community is really likely to benefit from the results.
>
>That may well be good advice -- I (personally, not as TAG chair) do 
>worry that the TAG sometimes proposes these task forces in situations 
>where there is a reluctance to hear the community say: "yes, the 
>current situation is suboptimal (e.g. two sets of specs in overlapping 
>spaces), but no, it's unlikely that much is going to change with or 
>without a task force".
>Even
>then, doing an analysis can have some value. I'm disappointed that we 
>haven't so far found ways to change either HTML or XML to bring them 
>closer together, but I think the team led by Norm is producing an 
>analysis that is very useful in pointing out what can be done with the 
>specs as they are, and also in leaving tracks so that the same 
>questions won't be repeatedly explored from scratch.
>
>Noah
>
>On 10/15/2011 4:05 PM, Larry Masinter wrote:
>> 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-sour

>>>>> ce/
>>>>> 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 Monday, 17 October 2011 21:16:08 UTC