W3C home > Mailing lists > Public > public-html-xml@w3.org > March 2011

HTML-XML Task Force Minutes 22 Feb 2011

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 07 Mar 2011 09:29:01 -0500
To: public-html-xml@w3.org
Message-ID: <m2hbbfovgy.fsf@nwalsh.com>

                                   - DRAFT -

                              HTML/XML Task Force

22 Feb 2011


   See also: [3]IRC log


           Mike, Henri, Norm, John, Noah





     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting 8 Mar 2011
         4. [8]Draft minutes from TAG f2f
         5. [9]Report update from Norm
         6. [10]EXI?
         7. [11]XML form submissions?
         8. [12]XBL
         9. [13]Any other business?

     * [14]Summary of Action Items


  Accept this agenda?



  Accept minutes from the previous meeting?

   -> [16]http://www.w3.org/2010/html-xml/2011/02/01-minutes


  Next meeting 8 Mar 2011

   Noah gives likely regrets for 8 Mar.

  Draft minutes from TAG f2f

   -> [17]http://www.w3.org/2001/tag/2011/02/09-minutes

   <noah> Note, those are draft TAG minutes, not yet reviewed as true record
   of the discussion

   Norm summarizes at a high level: more support for polyglot among some TAG
   members; desire for wider review in the community at large.

   Norm: I think the draft report is the best next step for getting broader
   ... Noah, do you want to add any color?

   Noah: No, not at the moment.
   ... I guess I'd add that the mindset was that the TF has done a good thing
   in categorizing the use cases. But we're not anywhere near anyone claiming
   that they've seen a solution or especially a solution that is new,
   surprising, or needs much more emphasis than it's been getting.
   ... So we're working on background material while the community continues
   at current course and speed. We might wish it was otherwise, but wishing
   doesn't make it so.

   Mike: Just skimming through the TAG minutes, it looks like documenting the
   use cases and best practices is the best that we might get.

   <noah> There is of course, still the hope that we may yet identify steps
   that will have more impact.

   Mike: Do others think that's a reasonable objective?

   Noah: I think the word "reasonable" is kind of tricky there. To put this
   much energy in and go no further seems like it would be unfortunate.
   ... Sometimes you do your best work and the result is neutral. I don't
   think we can say that we have to do something more, but I think we're
   doing the right steps.
   ... The goal is to do more, or just decide that it can't be done.

   Norm: I think that's roughly what I would have said. I think the next step
   is to get the document out. If the community nods its collective head,
   then perhaps we're done.
   ... If large portions of the community push back or offer new ideas, then
   I think it'll be our job to look at those.

   <noah> Right. My hope has been to do more. We've generated some insights
   and organized a bit of what's known, but we haven't had much impact on
   what people are spec'ing or building. Wishing doesn't make it so, but
   having such impact seems to me to be the goal of this work. Second choice
   is to decide reasonably efficiently that such impact is not achievable in

   Mike: So what's your plan for the document?

   Norm: My first step is to try to pull the use cases together into a common

   Some discussion of what else we might do.

   With little conclusion as to what else that might be.

  Report update from Norm

   Norm: Not ready yet. Distracted by other events, editor promises to
   deliver before next meeting.


   Norm: I got the sense that no one saw this as a new use case.

   Noah: It's the name of the technology. There were a whole bunch of use
   cases for EXI, did you have particular ones in mind?

   Norm: I didn't. It doesn't look relevant to me.

   John: I think we should write down a use case if we think there is one.

   Noah: Larry Masinter at the TAG meeting seemed to feel that what we'd
   written down wasn't really all use cases. I think writing down EXI is over
   the line.
   ... Getting some sort of efficiency benefit for HTML with EXI isn't
   directly relevant to what we're looking at.
   ... It could even become an anti-pattern. If users started shipping around
   EXI, that could complicate things for implementors having to support not
   just two serializations, but three.

   John: It still seems to me that shipping HTML over EXI is a reasonable
   thing to discuss.

   Mike: In an academic sense, but until we see some uptake...

   John: All of the things we've talked about are of dubious uptake.

   <noah> Right. So, in principle, EXI could be a plus for the HTML community
   if it proves to offer useful performance or size improvements, or it could
   be an antipattern if it raises expectations that HTML implementations will
   accept yet another encoding (of yet another serialization)

   <noah> Some of the EXI use cases are on the Web, as an alternative to gzip

   Mike: It's not clear that most of the EXI work is really "on the web" even
   if it is widely deployed.

   <noah> When and whether it's worth it I'm only partly convinced, but that
   is a use case for it.

   Henri: It seems to me that in theory this is all solved because EXI is
   something you can use to swap into in place of an XML parser. But in
   practice, it's not that straightforward.
   ... It seems to me that we could mention it, but that it wouldn't really
   be useful to write more about it. That's about using EXI as a compression
   mechanism for application/xhtml+xml.
   ... Robin was interested in using it to compress text/html. I haven't
   looked that closely, but I think it works something like SAX. It
   compresses events not characters.
   ... With text/html, when you have document.write(), for the
   document.write() semantics to work the right way, the parser has to have
   some sort of state that is relative to a stream of Unicode characters.
   ... So I think EXI works at a different level. This is a problem that
   would require some work, but simply defining it on application/xhtml+xml
   then it should just work.

   John: So that seems worth writing down.

   Henri: Since the situation is really one of theory not practice, I don't
   think it's worth trying to work on the text/html side at this point.

   Norm: I don't think this is another use case, but perhaps we should have a
   section in our document that talks about related technologies where we can
   put this sort of short summary.

  XML form submissions?

   <noah> Hmm. I have some doubts as to the details of using EXI with
   anything other than XML formats, but assuming it is used, I would expect
   that on deserializtion it could in fact conjure up a serial text stream if
   asked, possibly by wrapping it in a serializer layer. In practice, you'd
   probably want to optimize out that layering, but I would think the specs
   could probably compose OK, no?

   Norm: This one confuses me a bit because there's a mention of a UK govt
   requirement to submit forms in XML. But maybe that's really a question of
   getting the JavaScript to do the write thing with form submissions.

   Henri: I think the UK govt bit may be missleading. It sounds to me like
   some XForms vendor managed to get that written down. It's not clear that
   there's a real requirement here.
   ... I think it looks suspicious.

   Norm: I don't want to ascribe motivations, but just because something got
   written down doesn't mean it won't be changed. This is the sort of thing
   that might arise in wider review, but that doesn't mean this is

   Henri: The HTML forms used to have an XML submission format, but when the
   repetition model went away, it just became syntactic sugar. So it wouldn't
   actually give any new features. I don't think it really makes sense to add
   a submission format that's just a syntactic reformulation of the existing
   ... If someone wants to process the forms as XML on the server, they can
   just convert the existing submission format.

   Norm: I don't think there's more to be done now.


   Norm: I don't really know enough about XBL to have an opinion. Anyone here
   no more?

   Henri: I think XBL is not a use case but might be a solution to a use

   <noah> Just curious, would someone who has more stake in XForms be
   comfortable with the conclusions about syntactic sugar? If so, fine. If
   not, it might be good to hear the other side?

   <hsivonen> [18]http://dev.w3.org/2006/xbl2/

   Henri: But that draft may not enjoy consensus among the HTML community.
   ... The changes are probably a technical improvement, but perhaps were not
   socially best. I'm not sure that this draft will lead to interoperable

   Norm: Noah, we weren't talking about XForms at all in the last item.

   <noah> ok, thanks for the clarification.

   Norm: With respect to XBL, is it relevant?

   <noah> Hmm, is XBL similar in spirit to Microsoft XAML? XAML does very
   similar things building shadow trees that are then rendered.

   Henri: The idea is that there's a DOM tree that tries to be semantic, w/o
   a lot of div/span cruft. For example, if you have a plain input button but
   you want it to look flashy with SVG, you could have the XBL binding create
   a shadow tree that contained the flashy SVG implementation. But that SVG
   subtree wouldn't leak to the outer DOM.
   ... The scripts on the original page would see the plain DOM, but the
   rendering would be based on the shadow tree. So you can make the SVG
   button implementation a component that is bound to the normal DOM. The
   normal DOM doesn't change but you get the component in the rendered
   ... It's a way to decorate a document with components that are totally
   presentational w/o "contaminating" the original document.
   ... The relevance to HTML/XML integration is that the old XBL2 draft
   defined an XML vocabulary. It was possible to inline XBL bindings in
   XHTML, but it wasn't possible to inline them in text/html.
   ... The latest draft gets rid of the XBL namespace and adds a few elements
   to the HTML namespace. So in the latest draft, XBL2 becomes a logically
   self-contained part of the HTML vocabulary. If you put the bindings in an
   external file, then nothing much has changed.
   ... Putting these new features in the preexisting namespace is a fine way
   to avoid namespace proliferation.

   Norm: It doesn't sound like a new use case to me, but maybe worth
   mentioning like EXI.

  Any other business?

   None heard.

Summary of Action Items

   [End of minutes]


    Minutes formatted by David Booth's [19]scribe.perl version 1.135 ([20]CVS
    $Date: 2011/03/07 14:27:25 $


   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/2010/html-xml/2011/02/22-agenda
   3. http://www.w3.org/2011/02/22-html-xml-irc
   4. http://www.w3.org/2010/html-xml/2011/02/22-minutes#agenda
   5. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item01
   6. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item02
   7. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item03
   8. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item04
   9. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item05
  10. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item06
  11. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item07
  12. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item08
  13. http://www.w3.org/2010/html-xml/2011/02/22-minutes#item09
  14. http://www.w3.org/2010/html-xml/2011/02/22-minutes#ActionSummary
  15. http://www.w3.org/2010/html-xml/2011/02/22-agenda
  16. http://www.w3.org/2010/html-xml/2011/02/01-minutes
  17. http://www.w3.org/2001/tag/2011/02/09-minutes
  18. http://dev.w3.org/2006/xbl2/
  19. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  20. http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 7 March 2011 14:32:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:28 UTC