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 [email protected], 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/
