14:50:30 RRSAgent has joined #html-xml
14:50:30 logging to http://www.w3.org/2010/12/21-html-xml-irc
14:54:01 zakim, this will be xhtf
14:54:01 ok, Norm; I see XML_(TAG TF)10:00AM scheduled to start in 6 minutes
15:00:23 Yves has joined #html-xml
15:00:49 XML_(TAG TF)10:00AM has now started
15:00:56 +Norm
15:01:06 + +6681805aaaa
15:01:12 Julian has joined #html-xml
15:01:49 +Mike_Champion
15:01:58 zakim, aaaa is James
15:01:58 +James; got it
15:02:39 hsivonen has joined #html-xml
15:02:46 +Yves
15:03:18 jjc has joined #html-xml
15:03:25 +MKay
15:03:41 +??P19
15:03:50 zakim, ??P19 is Henri
15:03:50 +Henri; got it
15:03:56 zakim, who's on the phone?
15:03:56 On the phone I see Norm, James, Mike_Champion, Yves, MKay, Henri
15:04:33 MikeK has joined #html-xml
15:06:08 Meeting: XML/HTML Task Force
15:06:08 Date: 21 December 2010
15:06:08 Agenda: N/A
15:06:08 Meeting: 1
15:06:08 Chair: Norm
15:06:09 Scribe: Norm
15:06:11 ScribeNick: Norm
15:06:24 Present: Norm, James, Mike Champion, Yves, Michael Kay, Henri
15:10:20 Norm attempts to describe some of the background of the task force.
15:10:41 +John_Cowan
15:10:56 MC: TV Raman lead a discussion on AC-Forum back in the April time-frame.
15:11:08 s/lead/led/
15:11:56 JC: Perhaps someone could make that discussion public, as I don't have member access.
15:12:10 s/JC/James/
15:12:27 MC: It may all have been copied to www-tag
15:13:01 ACTION: Norm to review the ac-forum mail and see if he can summarize what wasn't made public.
15:13:04 see also the tag list (as opposed to www-tag)
15:13:28 q+
15:14:35 jcowan has joined #html-xml
15:15:47 are we going to use the queue?
15:15:55 yes, henri, sorry
15:16:29 q+
15:16:46 ack hsivonen
15:17:02 Norm decides to minute this telcon fairly lightly.
15:17:26 Some discussion of what we imagine the TAG's goal to have been in creating the task force.
15:18:21 Henri observes that there are two plausible goals: adding namespaces to HTML and making it possible to parse HTML with an XML parser.
15:18:40 q+
15:18:53 Henri: It appears that the popularity of namespaces is waning even in the XML community, so it doesn't make sense to add it to HTML.
15:19:00 -Mike_Champion
15:19:29 ...And it seems unlikely that the majority of HTML authors are going to produce XML-well-formed content, so that's not likely to be broadly successful.
15:19:49 +1 to Henri's points
15:19:58 ...I think something like tagsoup or my HTML5 parser that exposes an XML stream from HTML5 is a more likely to be successful approach.
15:20:03 ack jjc
15:20:28 +Mike_Champion
15:21:30 for the record, I think neither goal is "plausible" as a goal to pursue. they are goals I've heard from TAG members. :-)
15:21:44 JJC: Two goals expressed to me: figure out how to use an XML toolchain to produce web pages and in the future how to reduce the divergence.
15:22:13 ...Looking forward ten or twelve years, I think we should be thinking about how to make things better in the long run.
15:22:21 We already know how people process HTML as XML: they use TagSoup or Tidy or NekoHTML.
15:22:34 zakim, q?
15:22:34 I see jcowan, Yves on the speaker queue
15:22:40 ack jcowan
15:23:31 q+
15:23:36 JCowan: I think convergence has a use beyond parsing the wild XML; it's true it only works in closed contexts, but there are a lot of those.
15:24:26 ...the ability to embed HTML as a rich text island in "data XML" is a valuable thing and I think there should be a standard way to do this.
15:25:05 ...Polyglot documents focus on XML validity which I'm inclined to think is less valuable than it used to be. I'm more interested in XML well-formedness and HTML validity.
15:25:17 ack Yves
15:25:40 Yves: During the last TAG f2f we discussed the issue. I rember that Raman that having two different stacks, one for XML and one for HTML was costing a lot to all parties involved.
15:25:44 hober has joined #html-xml
15:25:52 ...He wanted more compatibility between tools and libraries.
15:26:05 ...At least that was my understanding.
15:26:10 ack hsivonen
15:26:46 Henri: Two points: first, it sounds like the existence of XHTML5 is getting forgotten. The HTML5 WG is already defining XHTML5 alongside HTML5. There's already a way to express the whole HTML5 vocabulary in XML.
15:27:23 ...The main difference is that you can have namespaces that the parser can't output. There are some fringe differences that you can have in HTML but not in XML, for example the FF character is whitespace in HTML but not XML.
15:28:14 ...So you can do distributed extensibility with HTML and you can embed HTML in XML with XHTML5.
15:28:55 ...Second, the question about software stacks, I think the problem is that people think that we're adding stuff when they see HTML5. But it doesn't add a stack, it documents the existing stack.
15:29:15 ...XML is the second stack, but it's not useful to point fingers about which is first or second, except to recognize that HTML5 isn't adding stuff.
15:29:39 ...Both stacks are more than a decade old, so neither is being added. One is simply being documented at this point. I think it's way past the point of avoiding adding a second stack.
15:29:41 q+
15:30:06 ...There are already at least three stacks and different communities: HTML, XML, and RDF. Treating the situation as if something is being added isn't really productive, I don't think.
15:30:12 ack jcowan
15:31:06 q+
15:31:08 JCowan: While those are all valid points, it seems to me that characterizing browser behavior as a stack makes it a kind of truncated stack. It simply renders. There's no transformation facility or other post-processing steps that can interevene.
15:31:23 ack hsivonen
15:31:59 Henri: The situation before the HTML5 spec is that IE was implementing DOM Level 1 so IE didn't recognize DOM Level 2 in the implementation sense. But gecko, presto, and webkit were implementing DOM Level 2.
15:32:53 ...So in all browsers except IE, the view to the data model has been the same for years. There were inconsistencies across the XML/HTML data models, especially with respect to namespaces.
15:33:45 ...HTML5 has codified the resolution of these inconsistencies. Now the data model is the same for XML or HTML, with a few small differences in the details.
15:34:11 ...Once the parser is done, the data model is the same now. That's something that's an achievement of HTML5. The same approach already existed on the non-browser side.
15:34:32 q+
15:34:55 ...First tagsoup and now HTML5 conformant parsers provide the same kind of API for both XML and HTML5. So I think we've gone a long way to unify the data model.
15:35:38 ...This means that as far as the stack goes, we've already done much of the unification. You can, for example, use an XSLT engine on HTML5 using the output of my HTML5 parser. It just works, whether the input is XML or HTML5.
15:35:51 ...I think it's a win that the stack is shallow, limited just to the parser and the serializer.
15:36:39 ...The question is can we unify the parser and the serializer? I think we could unify the serializer, but it seems unlikely to me that we can get more unification on the parser side. It would do violence to one side or the other.
15:37:02 ack jcowan
15:38:31 q+
15:39:22 Norm: I sometimes struggle to see what we should do, on the one hand long term harmonization seems like ti would be good, on the other, in the short term Henri's HTML5 parser and an HTML5 serializer do sort of "fix" the problem of how to read/write HTML5/XML together.
15:39:26 ack jcowan
15:40:18 JCowan: That makes me think that a possible outcome is a set of recommendations for the XML toolset to be able to serialize HTML5 instead of the current HTML serializer which is incomplete.
15:40:25 XSLT should definitely get an HTML5 output mode
15:41:00 Norm: Yes, clearly the XML serialization spec could/would/should/will get an "HTML5" serialization method.
15:41:16 MKay: Yes. We decided a year ago that it was too early to start looking at that, if we looked again now we might feel differently.
15:41:35 q+
15:41:42 ack jjc
15:42:13 James: I don't agree with Henri; I think there's plenty that one can do to make things better. But the way to go forward on that is probably to make some concrete use cases as Noah suggested.
15:42:29 q+
15:42:50 Norm: Yes, perhaps some use cases would be a good work item.
15:42:54 ack MikeK
15:43:18 MKay: I think one of the use cases is the one John Cowan mentioned, that is handling files that are data rich but include rich textual parts.
15:43:38 ...The other is the inverse of that, rich textual files that contain data either XML or RDF. Whether it's an existing XML vocabulary or a new one or a user defined one.
15:44:04 ...An important part of that is looking not just at the formats on the wire but also at the programming experience: both in generation and consuming/rendering.
15:44:22 ...We need to look at that whole picture from the perspective of processing, not just syntax on the wire.
15:44:51 Henri: Do you mean browsers providing a way to edit non-HTML data natively? Or do you mean JavaScript that might provide editing for the private data?
15:45:07 MKay: I mean the whole spectrum from wikis and form-based data across the whole spectrum.
15:45:59 Henri: The editing story for HTML is actually rather bad in terms of what actually works. I wouldn't expect browsers to be interested in addressing problems beyond editing HTML5 and perhaps SVG for a long time because they've already got lots of issues.
15:46:05 MKay: So there's room for improvement?
15:46:31 Henri: Yes, but I wouldn't expect generic editing to become part of the browser feature set anytime soon beyond what comes along naturally.
15:47:04 MKay: Perhaps architecturally what we'll see is editors as a client tool become a separate kind of tool from browsers.
15:47:22 Henri: I'd expect editing in the browser to be custom JavaScript.
15:48:10 Norm: What can we glean from the past 40 minutes or so for next steps?
15:48:34 ...use cases seems like a possibility.
15:49:08 MChampion: I had some good conversations at TPAC about some specific problems.
15:49:26 ...Could we write down and triage some of those?
15:49:54 q+
15:50:16 -James
15:51:34 Henri: Terminology-wise, "foreign" means MathML and SVG.
15:51:38 +James
15:51:56 Norm: Is there a term for random XML?
15:52:04 Henri: No, because it's not possible in text/html.
15:52:33 ...The specific issue that David Carlisle mentioned is about non-intuitive error handling.
15:52:50 ...If you stick to the cases where HTML5 is expected in foreign markup, then things work ok now.
15:53:01 ...The error handling isn't intuitive if you put them elsewhere.
15:53:10 JCowan: And is it to late to fix this in HTML5?
15:53:33 Henri: It's not a bug, it's a feature. It minimizes the risk to getting mathml and svg support deployed in browsers.
15:54:19 ...There is existing web content that contains math or svg tags. In order to keep those pages more-or-less backwards compatible, we have to have the current rules.
15:54:21 +q
15:54:40 ...The counter-intuitive behavior only arises if the document is an error. If you try to do sensible stuff, you don't see this behavior.
15:55:07 ...Even if we decided it was a problem, it would be too late to fix it. It's already shipping in Chrome and will ship in Firefox 4.
15:55:35 ack hsivonen
15:55:36 ack jjc
15:55:39 This spec is
15:56:07 q+
15:56:13 James: I'm troubled by this idea that there's nothing that can be changed in HTML5. HTML5 is a WD, if the W3C process means anything, the idea that something is frozen and static before it gets into last call is off base.
15:57:01 q+
15:57:10 ...I also completely disagree that one has to be constrained by what existing browsers do. There used to be two modes but folks have judged that that's not good. But the case could be made for the other decision.
15:57:32 ...The idea that there should be one mode and standards mode should be quirky is very disappointing.
15:57:35 q+ mchampion
15:57:39 ack jcowan
15:58:19 JCowan: I think there's a distinction between prospective and retrospective standardization. This is retrospective standardization and that does make things less fixable.
15:59:05 ...This may come to an end at some point, but I don't think it's appropriate to complain that they're not behaving like a prospective standardization group. They aren't because that's not where we are.
15:59:10 ack hsivonen
15:59:34 Henri: As far as the process goes, I think the W3C process is out of touch with reality as far as the implementation overlap with the specification process goes.
15:59:58 ...In theory you're supposed to start implementing after CR. But in practice, for something as complex as a browser, you need to have a constant feedback cycle.
16:00:16 ...It's unfortunate that the process document doesn't recognize this.
16:00:24 q+
16:00:53 ...It seems that the HTML5 WG gets more scrutiny on this point; I think the problem isnt the WG but the process document.
16:01:47 Henri: About the modes: there's a big difference between browser vendors on this point. In IE8, there are 4 modes; I think there are 7 in IE9. Other vendors with the experience of having 2.5 or 3 modes, have been pushing to remove modes.
16:02:14 http://hsivonen.iki.fi/doctype/#ie8
16:02:14 ...I think it's unrealistic for a WG or process to impose modes. Doing HTML5 with no new modes is how it has to be.
16:02:45 ack
16:02:48 zakim, ack
16:02:48 I don't understand 'ack', Norm
16:02:58 zakim, ack mchampion
16:02:58 I see Norm on the speaker queue
16:03:38 I regret I have to leave you now for another call. I'll stick around on IRC
16:03:46 -MKay
16:03:53 MChampion: I think to address Henri's point. This is implementation feedback, this is rapid integration with the waterfall model. There's a problem with real use cases. This isn't even a LC WD, in principle it should be open to a bug report from the XML community saying that this isn't going to work, especially if a reasonable fix was proposed.
16:04:24 ...I think it would be reasonable for this TF to triage the problem report. Does it effect enough users? Is it worth fixing, even if it introduces some churn in the HTML5 spec?
16:05:04 ...I wouldn't propose or preclude any particular solution. The mission I'd like to see for this TF is to assess how severe the problem is and to see if a solution can be proposed.
16:05:25 ...It may be too hard to change, but I don't think we should make that decision apriori.
16:05:27 -Mike_Champion
16:06:19 Norm: We're losing folks.
16:06:52 Adjourned.
16:07:00 -John_Cowan
16:07:01 -Henri
16:07:01 -Norm
16:07:02 -James
16:07:02 XML_(TAG TF)10:00AM has ended
16:07:03 rrsagent, set logs world visible
16:07:04 Attendees were Norm, +6681805aaaa, Mike_Champion, James, Yves, MKay, Henri, John_Cowan
16:07:06 rrsagent, draft minutes
16:07:06 I have made the request to generate http://www.w3.org/2010/12/21-html-xml-minutes.html Norm
16:07:13 jjc has left #html-xml
16:07:25 Yeeks, this is "light" minuting?
16:07:37 oh, not really
16:07:46 I was going to try to be light, but that's harder than not light, i guess.
16:17:45 ISTR that you've minuted the Core WG in the past.
18:02:57 MikeK has left #html-xml
18:36:36 Zakim has left #html-xml
20:03:40 Yves, are you still around?
20:05:27 hi norm
20:05:59 Hi. Just sent email. I need a URI space in CVS where I can store minutes, etc.
20:06:11 Under 2001/tag seems ... odd even if it is a TAG TF.
20:06:19 Under XML/ seems odder still.
20:06:28 Maybe 2010/html-xml ? I dunno. Anything you like :-)
20:06:31 I was about to say... under 2001/tag/ would make sense :)
20:06:47 oh.
20:06:57 That's fine then, I won't fuss.
20:07:01 2001/tag/html-xml ?
20:07:15 On the plus side, I probably still have CVS access to that part of the tree...
20:07:29 sounds good, but if you prefer 2010/html-xml that's fine as well
20:07:47 I can use some BOFH magic to give you access to that
20:09:00 has the tag created any other TFs? I don't recall...
20:09:18 I don't think so
20:09:28 ok I'll create 2010/html-xml, easier
20:10:24 ok. thanks.
20:10:40 hum, what is your login name? can't find it on cvs.w3.org
20:11:02 Maybe I don't have access anymore, I couldn't checkout 2010
20:11:14 NormanWalsh
20:12:41 2010 should restricted, I'll flip the acl so that 2010/html-xml works
20:13:08 done
20:14:35 sorry. color me confused. how can I co 2010/html-xml if I can't co 2010 first?
20:14:46 (and is 2010 really restricted where 2006 isn't?)
20:14:57 depends on the acl on directories
20:16:35 ok. so how do I get to 2010/html-xml?
20:16:35 and it should work the same as doing cd a/b/ while a/ is unreadable
20:16:43 cvs co WWW/2010/html-xml
20:18:44 hmm
20:18:55 $ cvs add 12
20:18:55 cvs.bin add: cannot mkdir /w3ccvs/WWW/2010/html-xml/12: Permission denied
20:19:08 weird
20:19:12 co seemed to work, but maybe I have ro perms?
20:19:36 no, it should be ok
20:19:39 let me check
20:19:54 $ cvs add 12
20:19:54 cvs [add aborted]: there is a version in 12 already
20:20:05 $ cvs update -d -P
20:20:05 cvs.bin update: Updating .
20:20:05 cvs.bin update: Updating 12
20:20:06 cvs.bin update: cannot open directory /w3ccvs/WWW/2010/html-xml/12: No such file or directory
20:20:06 cvs.bin update: skipping directory 12
20:20:34 ...but now it seems to be working.
20:20:35 ah I see 12 in it
20:20:36 Color me confused.
20:20:47 I changed the perms in the cvs repository
20:20:52 ah
20:21:02 when tools that are supposed to work don't, brute force can help :)
20:21:42 ok. I was able to create a file and I can see it on the web, so we're golden
20:21:45 thanks, Yves!
20:21:55 great! have fun ;)
20:22:00 heh