Hi, Its OK that you stepped in. Cause now I understand that what I said was not clear ;).
What I think is wrong with coming SVG1.2? It reminds me something built by the slogan: Lets take everything good around put it together and see what happend next". 1) Video and audion - its SMIL field with several years of pretty good performance and implemetations. 2) text flow, styles - its XHTML field. No need to say that there is no lack of browsers. 3) Forms and UI - its XForms field. Now the question is, why an SVG 1.2 should repeat all these efforts instead of to use them? Take a look at http://www.w3.org/2004/CDF/ Why W3C needs these new group? If everything is fine with SVG why to bother about... Take a look at this description there: "A Compound Document is the W3C term for a document that combines multiple formats, such as XHTML, SVG, SMIL and XForms. The W3C Compound Document Formats (CDF) Working Group will specify the behaviour of some format combinations, addressing the needs for an extensible and interoperable Web." Do you see now what I was talking about? Best, Andrew Girow http://www.tinyline.com --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <[EMAIL PROTECTED]> wrote: > I probably shouldn't jump in on such a charged topic, but I will anyway. > > On Tue, 24 May 2005 07:42:14 -0000 > "andrewgirow" <[EMAIL PROTECTED]> wrote: > > > Robin > > > > --- In svg-developers@yahoogroups.com, Robin Berjon > > <[EMAIL PROTECTED]> wrote: > > > andrewgirow wrote: > > > > If you mean that they overlap better that Don Demsak said? > > > > > > No, integrate. You just seem to have your own meaning of integrate > > that > > > doesn't cover other valid uses. > > > > > > > 2. Instead of integrating SVG amd SMIL animations such a way that > > SVG > > > > would deal with graphics and SMIL would deal with animations and > > > > time, the SVG INCORPORATED INSIDE (COPY AND PASTE AND CHANGE) > > Timing > > > > and Animation modules FROM SMIL. > > > > > > SMIL defines the way(s) in which host languages may use its > > features. > > > SVG complies to that. Not everything has been integrated yet, but > > it's > > > being done. I'm not sure you could've picked an example of a spec > > more > > > designed for reuse and integration that SMIL was -- you're proving > > my > > > very point here :) > > > > Look, I am not a researcher, but programmer. In my world > > (programming) when you say *integrate* means that you use some API > > and *link* your code (SVG) to another code (SMIL). When you do * > > *copy – paste* of some of the code, that happened in SVG 1.2 I > > named > > it as *copy - paste*. Again, you might be right, its understanding of > > code and efforts reuse from the programmer point of view. Nothing > > more. > > I'm also a programmer. Copy and paste coding is definitely a bad idea. > But we are talking about specifications here. Specifications are more > like an API than like code. SVG incorporated "some" of the interface of > SMIL. Since the committee was not comfortable (I'm guessing) with > incorporating all of SMIL, they carefully spelled out which parts were > included and how it affects surrounding elements. > > > Second, again from the programmer point of view when I have two > > modules: A and B and I read short descriptions like that: > > > > Module A: http://www.w3.org/Graphics/SVG/About > > "SVG is a platform for two-dimensional graphics. It has two parts: an > > XML-based file format and a programming API for graphical > > applications." > > > > Module B: http://www.w3.org/AudioVideo/ > > "The Synchronized Multimedia Integration Language (SMIL, > > pronounced "smile") enables simple authoring of interactive > > audiovisual presentations. SMIL is typically used for "rich > > media"/multimedia presentations which integrate streaming audio and > > video with images, text or any other media type." > > > > I never expect to find many parts of B module replicated in A. In the > > programmers world its called bad design of modules or they designed > > without looking at each other or without thinking how to use them > > together. Or they are not intended to use together from the begining. > > It wasn't all that long ago, that most C++ libraries came with their own > collections classes. Although this is not an optimal design, it was > required because the library writers could not depend on everyone having > one. > > We are at the beginning of this set of specifications, there will > always be points along the way when things are not quite right. The > alternative is to Haev everyone wait 10 years while a commitee works out > every variation and a small group of implementors tries every > combination and we don't get to do any work. > > Personally, I find SVG to be a lot of fun and very useful at the same > time. I would love to see better compatibility between the viewers and > better functionality as well. I also don't expect it to happen > overnight. > > Sorry for the pseudo-rant. > > G. Wade > -- > If there's no problem, there's no solution. -- Rick Hoselton ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
