<trackbot> Date: 10 June 2008

<scribe> Scribe: anthony

<aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0121.html

publication of SVGT 1.2 testsuite

AE: Erik sent an email to the public list
... with sort of a review
... do we feel comfortable releasing the test as is?

DS: Don't see what the problem is
... we can always add to the test suite

ED: Miss matching reference images are a small problem
... The incorrect reference images are a bigger problem

AE: Regarding the existing of tests that haven't been approved
... and have the draft water mark
... I think Chris was after feedback
... I don't mind either way

ED: Some tests looked more complete than others
... in my opinion I think we should fix the ones with serious errors
... such as mismatching reference images

AE: So what does everyone else think?
... there are people that may be waiting for the test suite
... e.g. OMA

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0103.html

ED: I guess another option is to publish my mail along with the test suite

AE: A list of known issues
... that might be a good compromise

AG: I'm fine with that

AE: So if we go ahead with this
... when can we publish it?
... my impression is that this is something Doug or Chris have to do

DS: I can probably publish it this week

RESOLUTION: We will proceed to with publication of the test suite package currently in CVS and we will package known issues along with it

<scribe> ACTION: Erik to Update list of known issues and add draft water marking back to tests that are still in their infancy [recorded in http://www.w3.org/2008/06/10-svg-minutes.html#action01]

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

ED: Should I put the list of known issues on the wiki

AE: Sure

status update for moving specs to public CVS

DS: Is that me?

AE: I seem to remember Chris saying he could do that task

DS: He's been a bit sick lately and hasn't been able to get to it
... I'd like to get to doing it this week if I can
... have a lot to do at the moment
... It shouldn't be too hard to transition it to it's new home
... just need a block of time to do it

AE: We have to coordinate on the list when we are going to do it
... so changes don't get lost

<ed> http://www.w3.org/Graphics/SVG/WG/track/actions/2039

<scribe> ACTION: Doug to look into problem with new tracker having incorrect links to minutes and notes in issues [recorded in http://www.w3.org/2008/06/10-svg-minutes.html#action02]

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

XHR review

DS: Both Erik and Cameron have sent in reviews
... I had already sent some comments earlier on my own
... I haven't had the time to do any more review
... I think Erik and Cameron have caught all of the big issues
... We should probably compile the two sets of comments together
... to send off

AE: Sounds good
... the comments have already been put on the list for some time
... so if any one had any issues with it they could start a discussion
... does everyone else agree with Doug's proposal?

ED: Sounds good to me

<scribe> ACTION: Erik to collate together Cameron's and your own comments for XHR and send them to the WebApps list [recorded in http://www.w3.org/2008/06/10-svg-minutes.html#action03]

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

HTML + SVG discussion

AE: So has everyone had a chance to read Tony's proposals?

AG: I did

ED: Yup

AE: I did too

DS: Yes

AE: There a number of ways is to go through the document
... if you read it did you have comments for the list or are your saving them for the telcon?

DS: Not sure on the best way to proceed

AE: We could use Erik's email as a focus point for discussion

ED: Is Power Point format file the way we want to present it?

DS: Wrong format for the audience
... need to present it into spec format

TZ: I was thinking of changing to HTML format after presenting it in Power Point
... what I could do is convert it to PDF

DS: We need to rework it into HTML
... needs to be a single document
... instead of a bunch of pages
... I can help do that

AE: So that make sense having it in HTML
... so we know it will be in a different format
... do we continue reviewing this?
... or do we transcribe this to HTML?

DS: There is also Erik's spec text
... I guess we will be making a couple of different proposals

AE: What is Erik's spec text?

ED: I will send the spec text out

AE: So let's just start with Erik's comments
... for the first comment
... - Slide "Interleaved Parsing of HTML - SVG"
... I guess it's just talking about the assertion of not being able to put HTML in SVG
... I agree with you there Erik
... So may it is just a matter for taking out the sentence

TZ: Not only is there complication from the parser side
... I would also think about rendering side of things
... I'm a little bit concerned about embedding HTML
... lets say we have HTML table inside a group
... and you start rotating the group
... what would you do with the table inside the group?
... this is the concern I have
... would it be a more complicated rendering model
... does this make sense to embed HTML in SVG

DS: Firstly there is a CSS transformations proposal by apple
... so I think they are very much interested way in bring in transformations
... in a compatible way with SVG
... I don't think that from the rendering perspective that it is a problem
... I don't think that particular rendering is the problem
... there may be other problems

ED: I suppose you could spec it like HTML would respect those elements
... I don't think it's a problem from the SVG point of view anyway

DS: I think the rendering problems are orthogonal to the parsing problems
... I actually have pretty good faith to work with us and the CDF working group
... to define the kind of rendering that we think is compelling
... that we think users are going to want to do

AE: So what I'm hearing is this sentence was to restrict the model
... we should probably put something to the effect that the HTML needs to be well formed when in the SVG

TZ: One thing I didn't quite get did you want me to incorporate those comments into the document?
... or Doug did you want to incorporate it into HTML

DS: However we want to do it is fine with me

AE: We probably need to get the HTML one done sooner than later

DS: If we can have somebody who wouldn't mind converting it to spec style HTML
... that would be good

ED: I guess I could do that
... bit pressed on time

DS: I have a feeling we are not acting in a timely manner

<scribe> ACTION: Anthony to convert the Power Point slides for SVG in HTML to a HTML spec-ish kind of document [recorded in http://www.w3.org/2008/06/10-svg-minutes.html#action04]

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

AE: To answer Tony's question any changes we make will go directly into the HTML document
... so is this our secondary proposal?

ED: So it's basically what we've started to discuss in the power point

AE: Should we start from this then?

ED: I think the Power Point document is a pretty good high level view of it
... from the HTML side of things they are looking for something like that
... based on the last draft that had SVG stuff in it

AG: Where to I put this HTML proposal?

DS: Could you just upload them into CVS?

ED: In the public one you mean?

DS: Yes

AE: I guess one of my concerns is that these things stay in sync with HTML
... mean track the changes in our HTML proposal

ED: Would be good to link to the last draft that had the svg stuff in it
... and maybe use bits from it

AE: As far as the first point goes we will specify rules for embedding HTML in SVG
... mainly that it has to be well formed
... For the next point it seems faily straight forward
... that's just something on your end Anthony
... to change these things to lower case

AG: Ok

AE: So the next one is the cascading parser structure

TZ: This was intended to be a high level diagram
... the reason why HTML parser is on the top because it is the primary one
... but maybe we need to restructure the diagram
... but I agree with you
... do we have any ideas how this should be structured?

ED: Could group all the parsers together
... maybe make on block a primary initial parser
... it might make it more clear

TZ: Do we want this tokeniser to be the primary parser?

ED: I guess it's not wrong to put it inbetween
... but it may not be required for all parsers

<ed> For document format XYZ: file input -> tokenizer -> parser (html, css, svg, xml, javascript)

<ed> and inside the parser box show the connections between different parsers

AE: So we are ok with putting the tokenizer step in between?

TZ: I had a page explaining it
... but Erik you had a problem with putting it in

ED: I had no problem with putting it in
... but I just wanted to point out that the the way the tokenizer is specced in HTML5 makes it too limited for proper use for XML

AE: Tony are you ok to take another shot at the diagram

<scribe> ACTION: zlatinski to Modify the cascading parser diagram [recorded in http://www.w3.org/2008/06/10-svg-minutes.html#action05]

<trackbot> Created ACTION-2061 - Modify the cascading parser diagram [on Atanas (Tony) Zlatinski - due 2008-06-17].

AE: The next comment there from Erik is the content provider

TZ: I agree the comment from Erik that "content provider" is not quite clear\
... language handler or content handler sound good to me

AE: Are there other terms used in the HTML 5 document that is familiar to them

TZ: It's a particular plug to handle a particular language

DS: I'd say content handler
... or sub-parser

TZ: Content handler sounds good too

AE: Sounds reasonable me too
... Anthony can you change content provider to content handler

AG: Ok

AE: The next one we've kind of discussed already

TZ: Do you have any idea how to address this problem

ED: You don't need a special tokenizer to handle each language
... if you read the HTML 5 spec
... the tokenzier throws away information about the casing
... 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

AE: Makes sense to me
... can keep sentence about special consideration
... Tony does that sound fine?

TZ: Yes

AE: Next one is slide for element identification

TZ: Maybe this part wasn't quite clear
... this is from the perspective of how you switch to a particular language
... we have to kind of reshuffle things around to make it more clear

ED: It still isn't clear enough to me what happens when it switches
... does it switch at the element you started parsing on
... or does it continue until it reaches something it can't handle
... that's my question

AE: Tony is that something we should discuss more

TZ: This is probably one of the major issues
... I could probably restructure this bit to make it more clear

ED: Which element you're currently in my define what the element is
... in a HTML <a> tag
... or an SVG <a> tag

TZ: From this perspective going back from the SVG to HTML

ED: That's what we need to define
... when to stop
... when to switch back
... in my opinion is we find an SVG element we switch to XML parsing
... and when we find the closing svg element we switch to HTML parsing

AE: Erik when you say XML well formed HTML in SVG
... is that XHTML or HTML that is well formed to XML

ED: As long as it's well formed

AE: What about casing, upper and lower mixture

ED: As long as the start and end tags match

TZ: I haven't done any examples or discussed it in any detail
... I can look into this section into more detail
... I could put a bit more work into that and make it more clear

AE: So this is the element identification section
... that's what you're talking about reworking those sections?

<scribe> ACTION: zlantinski to Revisit the element identification slides based on our comments [recorded in http://www.w3.org/2008/06/10-svg-minutes.html#action06]

<trackbot> Sorry, couldn't find user - zlantinski

ED: I'm just noting if you want tag soup HTML and SVG interleaved in any way you like
... it would work in their proposal but would not be conformant XML on the source level

AE: I noticed some parts are yellow, Anthony that's where you made changes?

AG: Yes

AE: Continue with the Jave script content slide

TZ: You don't see any cases where you'd like to have separate ECMA script
... like have a separate ECMA script context

<ed> <object data="some.svg"> will give you a separate script context

TZ: The document implied that the content handler would have a separate ECMA script handler
... you are saying that they should have the same context
... in the same DOM
... as soon as you get to a new content handler you make a new context
... so practically you're saying the control is from the child content not from the parent content

ED: Just from looking at how it works today, you get the same DOM
... I would expect it to be the same for HTML as it is in XHTML
... I think you should build the same DOM

TZ: I should change the section to make it clear that they have to be the same one
... and that the parent passes this down to the child
... this being the context

AE: Next one is CSS parsing

TZ: If we always enforce using the same document then we should use the same CSS rules

AE: Yes so it's the same as above
... do we need to discuss that section more or can we move on?

TZ: With regards to SVG widgets section
... just clarifying your comment Erik

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
... because it's a single context

ED: I think the idea of having SVG widgets that provide alternative recognition for SVG
... sounds a bit like XSLT or XBL

TZ: HTML doesn't have name spaces, so you put all the comment information inside the widget

ED: Could do that today with an XSL style sheet

TZ: So you're saying there is no point to talk about widgets at all?

ED: That's my opinion

TZ: Do you mind sending me an example
... of the concept

ED: Sure

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/this/the spec text/
Succeeded: s/latest draft of their spec/last draft that had the svg stuff in it/
Succeeded: 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/
Succeeded: s/HTML a tag/HTML <a> tag/
Succeeded: s/SVG a tag/SVG <a> tag/
Succeeded: s/in away/in any way you like/
Succeeded: s/conformant XML/conformant XML on the source level/
Succeeded: s/from HTML/for HTML/
Succeeded: s/XSBL/XBL/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: aemmons, ed, anthony, Shepazu, zlatinski
Present: aemmons ed anthony Shepazu zlatinski
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0121.html
Found Date: 10 Jun 2008
Guessing minutes URL: http://www.w3.org/2008/06/10-svg-minutes.html
People with action items: anthony doug erik zlantinski zlatinski