RE: Friction and cross pollination

Robin et al.
I respectfully disagree. We have a problem that we are trying to retrofit an existing project with something that should have been in the requirements document. Parenthetically, was there a formal requirements document for HTML5? If so, where can I locate it. 
I believe that we should be capable of coming up with a set of suggestions to solve the problem of HTML5 and XML interacting. This requires a direction to minimize any disruption to HTML5. My suggestion is to limit any changes to XHTML5. The next problem is outline what are the simplest effective changes that can be incorporated into XHTML5. One result of this approach is that all of those who are happy with HTML5 can continue developing software the way that pleases them. The rest of us who need to make or use products that use the very impressive capabilities of HTML5 and interface with XML, will have to produce reasonable suggestions of how to do this with XHTML5, which hopefully will no effect HTML5.
Bob Leif

-----Original Message-----
From: public-html-xml-request@w3.org [mailto:public-html-xml-request@w3.org] On Behalf Of Michael Champion
Sent: Friday, October 14, 2011 9:22 AM
To: Robin Berjon; Henri Sivonen
Cc: public-html-xml@w3.org
Subject: Re: Friction and cross pollination

> 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 Friday, 14 October 2011 18:37:02 UTC