12:31:24 RRSAgent has joined #svg 12:31:24 logging to http://www.w3.org/2008/06/10-svg-irc 12:31:26 RRSAgent, make logs public 12:31:26 Zakim has joined #svg 12:31:28 Zakim, this will be GA_SVGWG 12:31:28 ok, trackbot; I see GA_SVGWG()8:30AM scheduled to start now 12:31:29 Meeting: SVG Working Group Teleconference 12:31:29 Date: 10 June 2008 12:31:56 GA_SVGWG()8:30AM has now started 12:32:03 +??P4 12:32:12 zakim, ??p4 is me 12:32:12 +aemmons; got it 12:32:16 +??P5 12:32:17 +??P6 12:32:25 Zakim, ??P5 is me 12:32:25 +ed; got it 12:32:35 Zakim, ??P6 is me 12:32:35 +anthony; got it 12:35:02 Zakim, call shepazu 12:35:02 ok, shepazu; the call is being made 12:35:03 +Shepazu 12:36:14 +zlatinski 12:37:31 zlatinski has joined #svg 12:37:40 Scribe: anthony 12:37:48 Chair: Andrew Emmons 12:37:57 http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0121.html 12:38:08 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0121.html 12:38:41 Topic: publication of SVGT 1.2 testsuite 12:38:50 AE: Erik sent an email to the public list 12:38:55 ... with sort of a review 12:39:16 ... do we feel comfortable releasing the test as is? 12:39:30 DS: Don't see what the problem is 12:39:37 ... we can always add to the test suite 12:39:53 ED: Miss matching reference images are a small problem 12:40:04 ... The incorrect reference images are a bigger problem 12:40:30 AE: Regarding the existing of tests that haven't been approved 12:40:35 ... and have the draft water mark 12:40:44 ... I think Chris was after feedback 12:41:09 ... I don't mind either way 12:41:19 ED: Some tests looked more complete than others 12:41:31 ... in my opinion I think we should fix the ones with serious errors 12:41:39 ... such as mismatching reference images 12:41:56 AE: So what does everyone else think? 12:42:41 ... there are people that may be waiting for the test suite 12:42:52 ... e.g. OMA 12:43:13 http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0103.html 12:43:24 ED: I guess another option is to publish my mail along with the test suite 12:43:31 AE: A list of known issues 12:43:39 ... that might be a good compromise 12:44:08 AG: I'm fine with that 12:44:16 AE: So if we go ahead with this 12:44:22 ... when can we publish it? 12:44:42 ... my impression is that this is something Doug or Chris have to do 12:44:54 DS: I can probably publish it this week 12:46:34 RESOLUTION: We will proceed to with publication of the test suite package currently in CVS and we will package known issues along with it 12:47:45 ACTION: Erik to Update list of known issues and add draft water marking back to tests that are still in their infancy 12:47:45 Created ACTION-2057 - Update list of known issues and add draft water marking back to tests that are still in their infancy [on Erik Dahlström - due 2008-06-17]. 12:48:12 ED: Should I put the list of known issues on the wiki 12:48:14 AE: Sure 12:48:51 Topic: status update for moving specs to public CVS 12:48:57 DS: Is that me? 12:49:16 AE: I seem to remember Chris saying he could do that task 12:49:47 DS: He's been a bit sick lately and hasn't been able to get to it 12:49:57 ... I'd like to get to doing it this week if I can 12:50:14 ... have a lot to do at the moment 12:50:48 ... It shouldn't be too hard to transition it to it's new home 12:51:00 ... just need a block of time to do it 12:51:08 AE: We have to coordinate on the list when we are going to do it 12:51:30 ... so changes don't get lost 12:51:32 http://www.w3.org/Graphics/SVG/WG/track/actions/2039 12:52:56 ACTION: Doug to look into problem with new tracker having incorrect links to minutes and notes in issues 12:52:56 Created ACTION-2058 - Look into problem with new tracker having incorrect links to minutes and notes in issues [on Doug Schepers - due 2008-06-17]. 12:53:51 Topic: XHR review 12:54:05 DS: Both Erik and Cameron have sent in reviews 12:54:15 ... I had already sent some comments earlier on my own 12:54:40 ... I haven't had the time to do any more review 12:54:53 ... I think Erik and Cameron have caught all of the big issues 12:55:09 ... We should probably compile the two sets of comments together 12:55:13 ... to send off 12:55:17 AE: Sounds good 12:55:29 ... the comments have already been put on the list for some time 12:55:41 ... so if any one had any issues with it they could start a discussion 12:55:53 ... does everyone else agree with Doug's proposal? 12:55:58 ED: Sounds good to me 12:56:50 ACTION: Erik to collate together Cameron's and your own comments for XHR and send them to the WebApps list 12:56:50 Created ACTION-2059 - Collate together Cameron's and your own comments for XHR and send them to the WebApps list [on Erik Dahlström - due 2008-06-17]. 12:57:29 Topic: HTML + SVG discussion 12:58:05 AE: So has everyone had a chance to read Tony's proposals? 12:58:09 AG: I did 12:58:12 ED: Yup 12:58:14 AE: I did too 12:58:16 DS: Yes 12:58:40 AE: There a number of ways is to go through the document 12:59:03 ... if you read it did you have comments for the list or are your saving them for the telcon? 12:59:12 DS: Not sure on the best way to proceed 12:59:35 AE: We could use Erik's email as a focus point for discussion 12:59:51 ED: Is Power Point format file the way we want to present it? 13:00:06 DS: Wrong format for the audience 13:00:19 ... need to present it into spec format 13:00:40 TZ: I was thinking of changing to HTML format after presenting it in Power Point 13:01:19 ... what I could do is convert it to PDF 13:01:25 DS: We need to rework it into HTML 13:01:30 ... needs to be a single document 13:01:38 ... instead of a bunch of pages 13:01:41 ... I can help do that 13:02:30 AE: So that make sense having it in HTML 13:02:45 ... so we know it will be in a different format 13:02:56 ... do we continue reviewing this? 13:03:02 ... or do we transcribe this to HTML? 13:03:11 DS: There is also Erik's spec text 13:03:26 ... I guess we will be making a couple of different proposals 13:03:37 AE: What is Erik's spec text? 13:03:43 ED: I will send this out 13:03:56 s/this/the spec text/ 13:04:38 AE: So let's just start with Erik's comments 13:05:08 ... for the first comment 13:05:21 ... - Slide "Interleaved Parsing of HTML - SVG" 13:05:51 ... I guess it's just talking about the assertion of not being able to put HTML in SVG 13:06:00 ... I agree with you there Erik 13:06:13 ... So may it is just a matter for taking out the sentence 13:06:36 TZ: Not only is there complication from the parser side 13:06:43 ... I would also think about rendering side of things 13:06:53 ... I'm a little bit concerned about embedding HTML 13:07:04 ... lets say we have HTML table inside a group 13:07:10 ... and you start rotating the group 13:07:29 ... what would you do with the table inside the group? 13:07:40 ... this is the concern I have 13:07:53 ... would it be a more complicated rendering model 13:08:04 ... does this make sense to embed HTML in SVG 13:08:14 DS: Firstly there is a CSS transformations proposal by apple 13:08:27 ... so I think they are very much interested way in bring in transformations 13:08:37 ... in a compatible way with SVG 13:09:02 ... I don't think that from the rendering perspective that it is a problem 13:09:18 ... I don't think that particular rendering is the problem 13:09:27 ... there may be other problems 13:09:43 ED: I suppose you could spec it like HTML would respect those elements 13:09:56 ... I don't think it's a problem from the SVG point of view anyway 13:10:22 DS: I think the rendering problems are orthogonal to the parsing problems 13:10:48 ... I actually have pretty good faith to work with us and the CDF working group 13:10:57 ... to define the kind of rendering that we think is compelling 13:11:03 ... that we think users are going to want to do 13:11:22 AE: So what I'm hearing is this sentence was to restrict the model 13:12:09 ... we should probably put something to the effect that the HTML needs to be well formed when in the SVG 13:12:26 TZ: One thing I didn't quite get did you want me to incorporate those comments into the document? 13:12:46 ... or Doug did you want to incorporate it into HTML 13:12:53 DS: However we want to do it is fine with me 13:13:16 AE: We probably need to get the HTML one done sooner than later 13:13:43 DS: If we can have somebody who wouldn't mind converting it to spec style HTML 13:13:47 ... that would be good 13:13:52 ED: I guess I could do that 13:13:56 ... bit pressed on time 13:14:10 DS: I have a feeling we are not acting in a timely manner 13:16:31 ACTION: Anthony to convert the Power Point slides for SVG in HTML to a HTML spec-ish kind of document 13:16:31 Created ACTION-2060 - Convert the Power Point slides for SVG in HTML to a HTML spec-ish kind of document [on Anthony Grasso - due 2008-06-17]. 13:17:01 AE: To answer Tony's question any changes we make will go directly into the HTML document 13:17:40 ... so is this our secondary proposal? 13:17:59 ED: So it's basically what we've started to discuss in the power point 13:18:06 AE: Should we start from this then? 13:18:19 ED: I think the Power Point document is a pretty good high level view of it 13:18:37 ... from the HTML side of things they are looking for something like that 13:18:52 ... based on the last draft that had SVG stuff in it 13:19:56 AG: Where to I put this HTML proposal? 13:20:06 DS: Could you just upload them into CVS? 13:20:16 ED: In the public one you mean? 13:20:29 DS: Yes 13:21:24 AE: I guess one of my concerns is that these things stay in sync with HTML 13:22:04 ... mean track the changes in our HTML proposal 13:22:34 ED: Would be good to link to the latest draft of their spec 13:22:42 ... and maybe use bits from it 13:23:19 s/latest draft of their spec/last draft that had the svg stuff in it/ 13:23:40 AE: As far as the first point goes we will specify rules for embedding HTML in SVG 13:23:45 ... mainly that it has to be well formed 13:23:58 AE: For the next point it seems faily straight forward 13:24:07 ... that's just something on your end Anthony 13:24:14 ... to change these things to lower case 13:24:29 AG: Ok 13:24:41 AE: So the next one is the cascading parser structure 13:25:09 TZ: This was intended to be a high level diagram 13:25:36 ... the reason why HTML parser is on the top because it is the primary one 13:25:45 ... but maybe we need to restructure the diagram 13:25:49 ... but I agree with you 13:26:01 ... do we have any ideas how this should be structured? 13:26:08 ED: Could group all the parsers together 13:26:18 ... maybe make on block a primary initial parser 13:26:22 ... it might make it more clear 13:26:36 TZ: Do we want this tokeniser to be the primary parser? 13:26:49 ED: I guess it's not wrong to put it inbetween 13:26:57 ...but it may not be required for all parsers 13:28:39 For document format XYZ: file input -> tokenizer -> parser (html, css, svg, xml, javascript) 13:29:17 and inside the parser box show the connections between different parsers 13:29:32 AE: So we are ok with putting the tokenizer step in between? 13:29:42 TZ: I had a page explaining it 13:29:53 ... but Erik you had a problem with putting it in 13:30:32 ED: I had no problem with putting it in 13:30:46 ... but I just wanted to point out that the current tokenizer is too limited for XML 13:31:10 AE: Tony are you ok to take another shot at the diagram 13:31:42 ACTION: zlatinski to Modify the cascading parser diagram 13:31:43 Created ACTION-2061 - Modify the cascading parser diagram [on Atanas (Tony) Zlatinski - due 2008-06-17]. 13:32:01 s/current tokenizer is too limited for XML/the way the tokenizer is specced in HTML5 makes it too limited for proper use for XML/ 13:32:14 AE: The next comment there from Erik is the content provider 13:33:02 TZ: I agree the comment from Erik that "content provider" is not quite clear\ 13:33:21 ... language handler or content handler sound good to me 13:33:47 AE: Are there other terms used in the HTML 5 document that is familiar to them 13:34:33 TZ: It's a particular plug to handle a particular language 13:34:48 DS: I'd say content handler 13:34:55 ... or sub-parser 13:35:01 TZ: Content handler sounds good too 13:35:07 AE: Sounds reasonable me too 13:35:55 ... Anthony can you change content provider to content handler 13:35:59 AG: Ok 13:36:16 AE: The next one we've kind of discussed already 13:36:27 TZ: Do you have any idea how to address this problem 13:37:04 ED: You don't need a special tokenizer to handle each language 13:37:37 ... if you read the HTML 5 spec 13:37:51 ... the tokenzier throws away information about the casing 13:38:17 ... You could put an additional sentence saying as long as the tokenizer has to keep enough information to do both HTML and XML parsing on the output 13:38:52 AE: Makes sense to me 13:39:08 ... can keep sentence about special consideration 13:39:15 ... Tony does that sound fine? 13:39:17 TZ: Yes 13:39:35 AE: Next one is slide for element identification 13:39:43 TZ: Maybe this part wasn't quite clear 13:40:15 ... this is from the perspective of how you switch to a particular language 13:40:31 ... we have to kind of reshuffle things around to make it more clear 13:41:01 ED: It still isn't clear enough to me what happens when it switches 13:41:12 ... does it switch at the element you started parsing on 13:41:25 ... or does it continue until it reaches something it can't handle 13:41:32 ... that's my question 13:42:00 AE: Tony is that something we should discuss more 13:42:14 TZ: This is probably one of the major issues 13:42:25 ... I could probably restructure this bit to make it more clear 13:42:53 ED: Which element you're currently in my define what the element is 13:42:57 ... in a HTML a tag 13:43:02 ... or an SVG a tag 13:43:54 s/HTML a tag/HTML tag/ 13:44:04 s/SVG a tag/SVG tag/ 13:45:38 TZ: From this perspective going back from the SVG to HTML 13:45:43 ED: That's what we need to define 13:45:46 ... when to stop 13:45:53 ... when to switch back 13:46:11 ... in my opinion is we find an SVG element we switch to XML parsing 13:46:28 ... and when we find the closing svg element we switch to HTML parsing 13:47:53 AE: Erik when you say XML well formed HTML in SVG 13:48:10 ... is that XHTML or HTML that is well formed to XML 13:48:18 ED: As long as it's well formed 13:48:32 AE: What about casing, upper and lower mixture 13:48:44 ED: As long as the start and end tags match 13:49:18 TZ: I haven't done any examples or discussed it in any detail 13:49:29 ... I can look into this section into more detail 13:49:36 ... I could put a bit more work into that and make it more clear 13:49:54 AE: So this is the element identification section 13:50:04 ... that's what you're talking about reworking those sections? 13:50:51 ACTION: zlantinski to Revisit the element identification slides based on our comments 13:50:51 Sorry, couldn't find user - zlantinski 13:51:33 ED: I'm just noting if you want tag soup HTML and SVG interleaved in away 13:52:00 ... it would work in their proposal but would not be conformant XML 13:52:13 s/in away/in any way you like/ 13:52:27 AE: I noticed some parts are yellow, Anthony that's where you made changes? 13:52:30 AG: Yes 13:52:40 s/conformant XML/conformant XML on the source level/ 13:52:51 AE: Continue with the Jave script content slide 13:53:42 TZ: You don't see any cases where you'd like to have separate ECMA script 13:54:03 ... like have a separate ECMA script context 13:54:03 will give you a separate script context 13:54:54 TZ: The document implied that the content handler would have a separate ECMA script handler 13:55:01 ... you are saying that they should have the same context 13:55:05 ... in the same DOM 13:55:19 ... as soon as you get to a new content handler you make a new context 13:56:00 ... so practically you're saying the control is from the child content not from the parent content 13:56:11 ED: Just from looking at how it works today, you get the same DOM 13:56:30 ... I would expect it to be the same from HTML as it is in XHTML 13:56:45 s/from HTML/for HTML/ 13:56:53 ED: I think you should build the same DOM 13:57:09 TZ: I should change the section to make it clear that they have to be the same one 13:57:22 ... and that the parent passes this down to the child 13:57:31 ... this being the context 13:57:50 AE: Next one is CSS parsing 13:58:25 ChrisL has joined #svg 13:59:05 TZ: If we always enforce using the same document then we should use the same CSS rules 13:59:12 AE: Yes so it's the same as above 13:59:49 ... do we need to discuss that section more or can we move on? 14:00:19 TZ: With regards to SVG widgets section 14:01:18 ... just clarifying your comment Erik 14:02:07 AE: So you could have some CSS styling in the SVG but it will apply to any node in the document not just the SVG 14:02:24 ... because it's a single context 14:03:20 ED: I think the idea of having SVG widgets that provide alternative recognition for SVG 14:03:33 ... sounds a bit like XSLT or XSBL 14:03:46 s/XSBL/XBL/ 14:04:01 TZ: HTML doesn't have name spaces, so you put all the comment information inside the widget 14:04:17 ED: Could do that today with an XSL style sheet 14:04:30 TZ: So you're saying there is no point to talk about widgets at all? 14:04:37 ED: That's my opinion 14:04:46 TZ: Do you mind sending me an example 14:04:54 ... of the concept 14:04:56 ED: Sure 14:05:37 -aemmons 14:05:44 -zlatinski 14:05:52 -anthony 14:05:58 -ed 14:06:00 GA_SVGWG()8:30AM has ended 14:06:04 Attendees were aemmons, ed, anthony, Shepazu, zlatinski 14:06:15 Zakim, bye 14:06:15 Zakim has left #svg 14:06:21 RRSAgent, make minutes 14:06:21 I have made the request to generate http://www.w3.org/2008/06/10-svg-minutes.html anthony 14:18:32 MikeSmith has joined #svg