- 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>
[1]W3C
- DRAFT -
HTML/XML Task Force
22 Feb 2011
[2]Agenda
See also: [3]IRC log
Attendees
Present
Mike, Henri, Norm, John, Noah
Regrets
Anne
Chair
Norm
Scribe
Norm
Contents
* [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?
[15]http://www.w3.org/2010/html-xml/2011/02/22-agenda
Accepted.
Accept minutes from the previous meeting?
-> [16]http://www.w3.org/2010/html-xml/2011/02/01-minutes
Accepted.
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
review.
... 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
practice.
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
voice.
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.
EXI?
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
sufficient.
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
formats.
... 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.
XBL
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
case.
<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
implementations.
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
output.
... 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
log)
$Date: 2011/03/07 14:27:25 $
References
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