14:46:08 <RRSAgent> RRSAgent has joined #html-xml
14:46:08 <RRSAgent> logging to http://www.w3.org/2011/01/11-html-xml-irc
14:46:10 <Zakim> Zakim has joined #html-xml
14:47:01 <anne> not sure yet whether I'll dial in
14:47:09 <anne> I have quite the headache
14:48:23 <Norm> Ok. Thanks for letting me know. And I hope you feel better soon.
15:01:19 <noah> noah has joined #html-xml
15:01:26 <darobin> Zakim, this will be xhtf
15:01:34 <Zakim> ok, darobin; I see XML_(TAG TF)10:00AM scheduled to start now
15:01:52 <noah> zakim, who is here?
15:02:04 <Zakim> XML_(TAG TF)10:00AM has not yet started, noah
15:02:14 <Zakim> On IRC I see noah, Zakim, RRSAgent, darobin, anne, hsivonen, Yves
15:02:50 <darobin> weird
15:03:32 <noah> zakim, who is here?
15:03:46 <Zakim> XML_(TAG TF)10:00AM has not yet started, noah
15:03:52 <Zakim> On IRC I see noah, Zakim, RRSAgent, darobin, anne, hsivonen, Yves
15:04:01 <jcowan> jcowan has joined #html-xml
15:04:41 <hsivonen> ok. Zakim didn't show me joining
15:04:45 <Norm> Norm has joined #html-xml
15:05:38 <Norm> zakin, who's here
15:05:42 <Norm> zakin, who's here?
15:05:57 <Norm> zakim, who's here?
15:06:02 <Zakim> XML_(TAG TF)10:00AM has not yet started, Norm
15:06:07 <Zakim> On IRC I see Norm, jcowan, noah, Zakim, RRSAgent, darobin, anne, hsivonen, Yves
15:06:29 <MikeK> MikeK has joined #html-xml
15:07:45 <noah> meeting: xml/html task force call of 11 Jan 2011
15:07:49 <noah> scribenick: noah
15:07:58 <noah> date: 11 january 2011
15:08:05 <noah> scribe: Noah Mendelsohn
15:08:09 <noah> chair: Norm Walsh
15:08:33 <noah> regrets: James Clark, Anne van Kesteren
15:08:45 <mchampion> mchampion has joined #html-xml
15:08:55 <noah> topic: Administrivia
15:09:08 <noah> NW: Next call will be in a week, on 18 January.  Any regrets?
15:09:10 <noah> Silence.
15:09:31 <noah> topics: Use cases
15:10:00 <hsivonen> Use case email was http://lists.w3.org/Archives/Public/public-html-xml/2010Dec/0064.html
15:10:08 <noah> NW: I've been somewhat out of touch, but have seen at least two interesting email threads: 1) xml in feeds and 2) how to detect html5
15:10:23 <noah> JC: XML or HTML?
15:10:35 <noah> NW: Well, some thread subjects said XML
15:11:01 <hsivonen> we covered use cases 1 and 2. We didn't cover 3 and 4
15:11:50 <noah> Use case email was http://lists.w3.org/Archives/Public/public-html-xml/2010Dec/0064.html
15:12:02 <Norm> Norm has joined #html-xml
15:12:20 <noah> topic: Use case #3, islands of HTML5-marked prose
15:12:29 <noah> From the email description of the use case:
15:12:35 <noah> 3. I have an XML document and I want to embed islands of human prose
15:12:35 <noah>    marked up with HTML5 in it because I want to be able to extract
15:12:35 <noah>    those sections for use in, for example, documentation.
15:13:34 <noah> JC: In that environment, we don't have an HTML5 DOM, I think, so we don't have to deal with inconsistent DOMs
15:13:44 <noah> NW: Yes, mainly XML tools for this case.
15:14:05 <noah> JC: What limitations are there on HTML5? E.g., I know about noscript.
15:14:49 <noah> NW: (missed something about semantics) I was thinking about things like HTML5 rules that automatically add namespaces to SVG, and that won't happen in an XML toolchain.
15:15:28 <noah> JC: The XHTML5 elements mean the same as their like-named counterparts in HTML5, with the exception of NOSCRIPT
15:15:36 <noah> HS: Yes, and also ISINDEX
15:15:38 <noah> NW: Why?
15:16:12 <domel> domel has joined #html-xml
15:16:28 <noah> HS: Those are both sort of parser-managed things on the HTML side. ISINDEX as sort of a parser macro, is invalid into HTML5, and is invalid in that sense.  It expands into other elements like a macro.  NOSCRIPT depends on the context.
15:16:52 <noah> JC: How it's parsed depends on whether you have scripting.
15:17:25 <noah> NW: Thanks, good to know. Sounds like it's safe to set aside ISINDEX.  Less sure about NOSCRIPT, but likely at worst a minor problem.
15:17:53 <noah> topic: Use case #4, HTML document with islands of XML
15:17:57 <noah> From the use case email
15:18:13 <noah> 4. I have an HTML5 document and I want to embed islands of XML in it
15:18:13 <noah>    because I want to be able to write JavaScript and CSS to manipulate
15:18:13 <noah>    those elements, for example, in the browser.
15:19:14 <noah> NW: The HTML5 parser won't do the same thing as XML would if the element names are in the HTML5 language.
15:19:51 <noah> NW: I believe that the only workaround is to put the XML in a <SCRIPT> element, that gives you the XML in an escaped node.
15:19:58 <noah> MK: Or download the XML separately.
15:20:06 <noah> HS: The text node will have the text unescaped.
15:20:19 <noah> NW: Oh, OK, yes.  If serialized then escaped, but in the node it's not.
15:22:22 <noah> NM: The XML need not be for manipulation only in Javascript/CSS, you may also or instead want to manipulate it in XML (or HTML) tools at the server, or conceivably elsewhere on a client.
15:25:28 <noah> HS: The script element trick works for all languages, so XML is being treated as a special case.
15:26:51 <noah> NM: Yes, and there are arguments pro and con as to whether that makes sense.  HTML and XML have a long history togther, and this task force is focused on exploring synergies.
15:26:56 <noah> JC: Just use XHTML?
15:27:21 <noah> NM: Yes, but we always get back to the huge install base that runs best with text/html
15:30:18 <darobin> "The script element allows authors to include dynamic script and data blocks in their documents. The element does not represent content for the user."
15:33:15 <noah> NW: I find the uniformity of treatment of all languages by NOSCRIPT to be appealing.
15:33:41 <noah> NM: So, I'm a little troubled by the fact that <SCRIPT> tags have mandated processing in the case there's a script there.  What if the script is media type applicaiton/xml
15:34:17 <noah> JC: Not troubled by that.  You'll use something like application/xslt+xml if you want your XML interpreted as (in this example) an XSLT script. 
15:34:37 <noah> JC: Historically, media type is what to do with it, not what it is.
15:34:48 <Norm> Norm has joined #html-xml
15:34:49 <noah> NM: I strongly disasgree with that.
15:35:24 <noah> JC: Oh, I mean in HTML
15:35:34 <noah> NM: Specifically on the SCRIPT tag
15:35:38 <Norm> scribe: NM
15:35:40 <Norm> I'm not sure I'd go so far as to say that I found it appealing, but ...
15:36:50 <hsivonen> q+
15:37:02 <MikeK> q+
15:37:51 <noah> NM: I'd prefer to associate the processing rules with the spec for the SCRIPT tag
15:37:59 <noah> JC: What does the HTML5 spec say?
15:38:00 <Norm> ack hsivonen
15:38:38 <noah> HS: I agree with Noah that in principle there's an architectural issue; in practice the set of languages supported in browsers is small and slowly growing.  So far none in XML.  If necessary, any such new XML scripting language could get a more specific type.
15:38:54 <Norm> RRSAgent, set logs world-visible
15:38:58 <noah> Speaking for myself: OK, maybe the HTML5 spec should say what Henri just said.
15:39:03 <noah> JC: XSLT?
15:39:19 <noah> HS: They don't support it in <SCRIPT>, and it doesn't make much sense to do so.
15:40:23 <noah> JS: I understand this isn't likely to happen, but not sure why it wouldn't make sense.
15:40:55 <noah> HS: Script processing starts when end tag </script> is parsed, and you only have a partial DOM. Seems not to make sense to do XSLT then.  Hmm, but a DEFER script could make sense I guess.
15:41:13 <noah> JC: Could run multiple successively.
15:41:30 <noah> q+ to talk about circularity
15:41:39 <Norm> ack MikeK
15:42:27 <noah> MK: Some of my points have been partly covered.  There are a lot of potential XSLT processing scenarios, many of which can't be captured by <script type="..xslt type..">
15:42:47 <noah> MK: E.g. when to run, what the input is, whether there's more than one script, etc., parms, etc.
15:43:38 <hsivonen> q+
15:43:53 <noah> MK: Relying on one attribute seems insufficiently extensible.  Henri reinforces that when he says "won't happen in next year, therefore uninteresting".  Seems the wrong way to architect.  We should look further into the future, to when Javascript seems as old fashioned as COBOL. The world is dynamic.
15:44:10 <noah> JC: Propose we add embedded XSLT as another use case.
15:44:14 <noah> NW: +1
15:47:15 <noah> NM: Too bad we're leaving this behind so quickly.  The purpose of our group is to maximize HTML/XML synergies, and for >certain< purposes XSLT is a terrific language for HTML scripting
15:47:52 <noah> HS: There is some implementation in the runtimes for giving the HTML DOM as input to XSLT processing (scribe isn't sure he got this right)
15:48:25 <noah> HS: The XSLT program can be put in a script element, and use bootstrapping Javascript that compiles the XSLT program, and chooses as input tree to give to that program.
15:48:36 <noah> HS: You can put the output in the DOM.
15:48:42 <noah> q?
15:48:44 <noah> ack noah
15:48:44 <Zakim> noah, you wanted to talk about circularity
15:49:28 <noah> MK: Yes, we've seen the folks at ETH Zurich do just that, using two <SCRIPT> elements, one javascript and one XQuery.  The former looks for and runs the latter.
15:50:44 <noah> HS: The set of programming languages supported natively by browsers has always been "1" across multiple browsers, that is Javascript.  Internet Explorer has for years also supported VBScript.  There are also good accessibility(?) APIs that allow languages to be plugged in.
15:50:44 <Norm> ack hsivonen
15:51:01 <noah> HS: Gecko allows some extensibility, but for various reasons only for local content.
15:51:34 <noah> HS: Anyway, the trend is toward focus on Javascript only, and viewing that as a compiler target for other languages.  That said, there is precedent for having other languages.
15:52:03 <noah> HS: You cannot ever use type="text/vbscript" for data, because there exists a browser that would attempt to execute it.
15:52:20 <noah> BINGO!  That's why I don't much like using the <SCRIPT> tag for data.
15:53:06 <noah> NW: That is astonishingly unsatisfying.  It would make much more sense to add a new <DATA> element, without the risk that IE would later decide that type="application/fribble" would launch missles.
15:53:30 <noah> HS: The reason it's called SCRIPT and not DATA is that there are only a handful of elements that don't try to parse their content.
15:53:52 <noah> HS: If we introduce something called <DATA>, it would be incompatible with the install base of browser.
15:54:22 <noah> What about <script type="xxxx" mode="NORUN">?
15:54:54 <noah> q+ to ask about NORUN attribute
15:55:42 <noah> HS: So, the pattern is formalized in HTML5.  An alternative is using <STYLE>. Another is <XMP>, but that's not hidden by default.
15:56:44 <noah> NW: Yeah, I forgot the compatibility problem.
15:56:56 <Norm> ack noah
15:56:57 <Zakim> noah, you wanted to ask about NORUN attribute
15:57:22 <hsivonen> existing browsers wouldn't honor NORUN
15:58:22 <jcowan> Announcement: I'm working on a MicroXML parser/DOM called MicroLark (hommage to Tim's Lark parser from the early days of XML)
15:59:37 <Norm> rrsagent, draft minutes
15:59:37 <RRSAgent> I have made the request to generate http://www.w3.org/2011/01/11-html-xml-minutes.html Norm
16:00:08 <noah> NM: I think a new attribute would have fewer problems BUT: I admit that it would be at best eliminating future problems, and then only rarely.  The advantage would be architectural robustness.  It appeals to me intellectually, but I suspect that even if built it would be used only sometimes.
16:00:13 <noah> NW: We are ADJOURNED.
16:01:07 <MikeK> MikeK has left #html-xml
17:00:52 <domel> domel has left #html-xml
18:16:36 <Zakim> Zakim has left #html-xml