Accept this agenda?

http://www.w3.org/2010/html-xml/2011/02/22-agenda

Accepted.

Accept minutes from the previous meeting?

-> 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

-> 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> 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.