See also: IRC log
<trackbot> Date: 01 April 2010
<scribe> Scribe: Anthony
<scribe> ScribeNick: anthony
ED: I said that next telcon is
canceled
... it'll be a public holiday for some
ED: next one on will be April,
Thur 8
... The time suggested by the script was
... Monday and Thursdays
... 8PM UTC
DS: So it's an hour later
... the time is fine for me
... for JW it's 9pm and CL it's 10pm
ED: My suggestion is to try this
time for this telcon
... and see how it goes
PD: Sounds like it's a good idea
ED: Do we need to book this now?
PD: I say do it now
DS: I'll book this now
ED: We were kind of late with
publishing some documents
... so not meeting the heartbeat requirement
... I remember we resolved to publish some specs
... but I couldn't find any resolutions when I searched through
the mailing list
PD: I remember there was a whole
series of documents
... are we concerned with a certain one?
ED: Mainly we were concerned with
publishing modules
... Filters, composting
PD: Don't really understand the publishing process
DS: There's a heartbeat
requirement
... where we are suppose to publish every 3 months
... we have Editors Draft
... which is fairly new in W3C
... then there is First Publich Working Draft
... where a company looks at it's IP and decides to go a head
with it or not
... then there is Working Draft
... then it goes to Candidate Recommendation when we think it
is almost done
... then there is Proposed Recommendation where people get a
chance to comment
... then it moves to Recommendation status
<patrick> http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
PD: Looking a Wiki road map
ED: That's a bit off
DS: We've been really slowed down
by SVG 1.1 2nd Edition
... I think it's were all over worked
PD: I don't want to add anymore slowness
ED: To push out 2nd edition would
require some more work on test suite
... and some spec work
... which isn't too much more work
PD: So I saw some drafts on
Params, gradients
... and is it a matter of picking bits of those
... then building 2.0 or is it starting from scratch?
DS: We have two different markets
we are trying to satisfy
... Browsers and then mobile platforms
... The modules allow people to add SVG 2.0 functionality to
their browsers
... once we know what modules we will have for 2.0
... we will collect them together with some other bits and we
develop 2.0
... that way other user agents can inch their way to 2.0
PD: I would like us a WG to take
a far step back and look at SVG
... e.g. reduced DOM
... so if were to do something like reduced DOM would that be a
new module or a chapter?
DS: I could see the DOM as a module, but would probably be part of the core specification
PD: Would the original DOM be part of the spec if we go with a new one
DS: Personally, I think parts of
it would be
... but we have an opportunity to redefine it here
... but it mainly getting the browser vendors to agree on new
functionality
PD: So then what's the responsibly. Would you list the old DOM bits optional and deprecated?
DS: Yes
ED: We will try to set up some more joint telcons for FX
PD: That sounds great
... looking forward to the F2F
ED: From my personal opinion
there are definitely parts of SVG 1.1 DOMM
... that are heavily used and useful
... then there are parts that are not well thought out
... if you ask anyone who's implemented SVG
... they will say they that there are parts that they'd like to
change
PD: What about higher level
DS: We have most of the browser
vendors participating
... we have people from Adobe if they want to participate
... I saw some Silverlight stuff that looked appropriate for
SVG and some of it was not
... if we are going to set the course of future web graphics
then we should take a look at some of these things here
... I think there is some useful stuff that we could be adding
to SVG
... Parameters is one of those things that is not backwards
compatible but most people have loved it
... and if you do that then most of the older SVG content in
those older browsers will not work when using this
... I think we have a unique opportunity to change things
now
PD: So in summary we're not going to do a bottom up approach but more top down
ED: So you're thinking more of a functionality and feature thing?
PD: Yes
DS: One examples is gradients for
example
... SVG currently offers radial and linear gradients
... but I'd like as an author to have gradients along a
path
... or something like gradient mesh or diffusion curves
... so we could come in from either end when designing SVG
ED: This is definitely an
interesting discussion to have. Should have this at the
F2F
... having backwards compatibility is really important
... but certainly being able to extend it
DS: I think we'd have to figure
out in the details
... what to preserve and what to move forward with
<shepazu> http://dev.w3.org/SVG/profiles/2.0/publish/
DS: Patrick you need to get your name on this as well
<ed> http://dev.w3.org/cvsweb/SVG/profiles/2.0/publish/
DS: this didn't seem to print out a table of contents
ED: Try the second link I pasted
DS: I thought metadata wont change much
<ed> http://dev.w3.org/SVG/profiles/2.0/publish/metadata.html
DS: I took sections from 1.2 Tiny
that you didn't think would change much
... and started adapting them
<shepazu> http://dev.w3.org/SVG/profiles/2.0/publish/intro.html
DS: so far the most energy has
gone into the intro page
... to set the tone what we are going to be doing
... there's just a few pages so far
... a few chapters
... I included linking
... because I want to talk about Link Href
ED: That's one of the features
that need to be changed because it's slightly different in
Tiny
... quite like the page with the linking elements
<shepazu> http://dev.w3.org/SVG/profiles/2.0/publish/linking.html
DS: What I want to do is allow 'src' on image
<ed> ED: the linking restrictions were not as restricted in tiny 1.2, so needs to be changed to represent 1.1 full
DS: or have it on use as
well
... anything that is sort of inbound
... and for replacement content
... and that leads us to a question
<shepazu> <image xlink:href="foo.png" src="bar.jpg" ... />
DS: what if you have something
like this
... what do you do?
PD: Xlink wins
DS: What does the DOM look like?
PD: It has both
AG: I agree with PD on both of those
<shepazu> <a xlink:href="foo.svg" href="bar.svg"> </a>
ED: Probably makes the most sense
<shepazu> myEl.href = "blah.svg"
ED: Doesn't mean to say a new user agent wouldn't have a simpler way of accessing the link
DS: What happens in the above case?
PD: Both are in the DOM?
DS: Yes
... my proposal is href changes both
PD: Mirrored?
DS: Yes mirrored
PD: I don't like mirroring but at the same time this is an edge case
DS: I think it's where things are backwards compatible
ED: I'm not very fond of
mirroring
... just trying to think of the case for backwards
compatibility
PD: It tends to have an
unpredictable ripple effect from design and code
... you want to start moving on this right?
DS: Yes, I want to have something quantified
<shepazu> (and what would the namespace of the property be?)
DS: we talked about this on the mailing lists and with other groups in the past
PD: Is there anything similar already out there?
ED: I think going over all the
events and all the event attributes
... is something we need to do
DS: One thing we could do is just
say not add src
... just add href
PD: I think href is a great start
DS: There are some people that
will get confused
... I actually don't know. I think people would like to get rid
of the name space stuff
PD: I think what we are saying though is that href is becoming part of the SVG name space
DS: I mean right now what's
reflected in the DOM
... the href would have the xlink namespace
PD: I presumed href would be part of the NULL name space
DS: What is the name space of
that property?
... if we allowed just bare name href
PD: What are we holding up on? Why is this so hard?
DS: The question is when you're
parsing the document and you encounter xlink:href it is very
clear what you need to do
... if you're parsing a document and it has SVG image href
without the xlink
... it puts the value in and it puts in a NULL names
space
... what does the serialisation say?
... if they both exist in the DOM what happens?
ED: I think they can have
independent values in the DOM
... and serialise them as you would currently in browsers
DS: You can't have two values
with the same name
... one has prefix
... what if use dot notation to set it?
... which one does it change/set?
ED: It changes which one we decide it to change
DS: Honestly I don't care what
the answer is
... it's messy either way
<scribe> ... new people to SVG struggle with this one
PD: we say xlink:href preceeds it and if .href is used what is changed xlink:href or href?
DS: So opening up content in
illustrator may break as well as a result
... is it worth getting rid of name spaces
AG: What was the advantages of having name spaces in SVG?
DS: You can use name spaces and
prevent conflicts
... so say I wanted to put in some geolocation information in
an SVG map
... I can distinguish between different sets of data using name
spaces
... the mapping example is just one case
... it lets you structured data to SVG
... so in general I think some cases it's useful but with
xlink:href it's not so much
PD: How often are name spaces used on the web outside of SVG
ED: XSLT style sheets outputting XHTML and HTML
PD: Is that done a bit?
ED: I've seen it out there
DS: If it's supported it may be done some more
ED: If we do drop xlink:href we need the tools to follow
DS: Don't think we're closer to coming to a conclusion
ED: Would be nice to collect all
the thoughts and discussions on this
... we need a vote on this
AG: Might be good to ask the IG what they think
DS: What should I put in the SVG 2.0 spec next?
ED: I don't think coordinate systems would change that much
<ed> basic shapes too probably
AG: We should consider adding
information about processing elements
... and what steps should be done to process an element
... e.g. the spec talks about "at the time of reference" in
various areas
... and it is unclear at what point in the processing are
things reference
... this is an architectural that we should look at early on in
the piece
ED: So one little thing about
publishing documents
... you said you'd look through the mailing list for decisions
to publish
... I really think we need to get some documents out soon
DS: Lets talk about that next Thursday
<scribe> ACTION: Doug to Search through the minutes and look for where the group has made resolutions to publish [recorded in http://www.w3.org/2010/04/01-svg-minutes.html#action01]
<trackbot> Created ACTION-2751 - Search through the minutes and look for where the group has made resolutions to publish [on Doug Schepers - due 2010-04-08].
<patrick> http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2
PD: I've updated the list
DS: Can you please send an email
out to let people know
... about the list
... and perhaps assign people to tests
... CL would be good with styling and stucture
ED: There are a couple more
tests
... that need review
... slightly more complex
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/sence/sense/ Succeeded: s/image/link/ Succeeded: s/XHTML/XHTML and HTML/ Found Scribe: Anthony Inferring ScribeNick: anthony Found ScribeNick: anthony Default Present: [Microsoft], Shepazu, [IPcaller], ed, anthony Present: [Microsoft] Shepazu [IPcaller] ed anthony Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2010JanMar/0110.html Found Date: 01 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/01-svg-minutes.html People with action items: doug[End of scribe.perl diagnostic output]