See also: IRC log
http://www.w3.org/2010/html-xml/2011/02/22-agenda
Accepted.
-> http://www.w3.org/2010/html-xml/2011/02/01-minutes
Accepted.
Noah gives likely regrets for 8 Mar.
-> 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.
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.
<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.
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> 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.
None heard.