The 0.9x class of standards is outdated and underdocumented. The 2.0 class is highly underdocumented, filled with unnecessary features though lacking others which could be useful. The RSS 3 standard is supposed to extensively document the standard, to expand where expansion is needed and to remove unnecessary features.
Is any of you satisfied with the explanation that the world needs a new RSS standard because the other versions are not well documented? What on earth stops him (Jonathan Avidan) from documenting them properly?
Also worth mentioning is that the Atom syndication standard, currently in development, is out of this standard's scope and does not concern it. Due to contradiction in structure, the standards cannot rely on one another, yet an implementing client should support both standards.
How about all five RSS 0.92, RSS 1.0, RSS 2.0, RSS 3.0 and of course ATOM. This will be really a joy for implementers.
You don't think Flash and SVG can live side by side?
Well, on way or the other they will have to live side by side. The question is whether their marketshares will become somehow comparable or not. Actually, nobody will complain for having Flash support in her/his browser, as long as there is also SVG support. And Opera and Firefox will hopefully have built-in SVG support soon enough.
For me personally, the prospect of SVG in the near future lies in non-animated interfaces - Application skins (go from bulky Media Player to slick Winamp with two clicks), faster loading of graphics-heavy web pages, building on previous work easily by checking the source of pages, getting away from non-XML syntax for advanced styling (CSS), and such.
None of these applications will be easy (or even possible) to use without a good SVG viewer.
Have you ever tried viewing the source of a Flash file?
Yes I did, and I also do know the advantages and disadvantages of both Flash and SVG. Nobody in this conversation tried to deny the technical merits of SVG. But for one technology to achieve widespread use, technical merit is never enough.
Yes, I like SVG too, and I would love to see more people using it. But this doesn't mean I will go blind and not notice its tiny market share or its very slow adoption rate. And these problems are very much agravated by the lack of complete viewers. You know, designing a complex XML vocabulary like SVG is much simpler than building the tools to actually use it.
No. SVG has to compete with Flash. And the widespread adoption of Flash by both the commercial and open source (e.g., OSFlash, OpenLaszlo etc.) communities was caused by the fact that Flash is a good platform to develop for, and has a consistent and ubiqutous Flash Player. It has nothing to do with semantics (and it never will) or scaling or anything else. No sane company would target a platform that doesn't even have good viewer. Very few developers will go through the pains of building a serious SVG application if nobody can use it.
Well... we went through those pains, and probably will do so even more in the future. But we are doing this only with the hope that, one day, people will also be able to easily use our applications.
If SVG was released when CSS was (i.e. ten years ago), maybe your argument would have made sense. You say that "SVG is the only way to separate the content of images from their presentation, and to make them properly scalable" and you are wrong. Flash has allowed this for many years now. No, it is not a standard, but it seems that nobody other than you and me cares about it. And, well... why should they?
Nobody has ever made a full implementation of CSS2, and it's very popular.
This is a very different story. CSS had to compete with unstructured HTML code full of font and color tags, and it was clearly a technically better solution (although complex). Everybody is using CSS because it is the only way to separate the content of a web page, from its presentation. And because CSS is extremely popular CSS2 has a clear road ahead.
The situation of SVG is very different. Macromedia Flash is already a very mature platform that already almost everything that SVG does now years ago and it did this in a very coherent way (they don't have to worry too much about interoperability). The Flash Player is installed on almost every networked computer, and it works the same everywhere. If SVG wants to have the smallest chance of replacing Flash it will have to match this. So full implementations of the SVG standard are not just nice extras, they are mandatory for the success of SVG.
Complete implementation? No. But pretty much every feature has been implemented and tested in some implementation as of the end of last year
The page was last updated on 2003/08/12 18:41:23, so it was published two years from now. The problem is that every feature has been implemented and tested in a different implementation. It would be really helpful to have complete implementation(s).
Not to knock the great work Inkscape has done, but it's not the most advanced. I would guess Adobe SVG Viewer is better as a viewer. It's definitely been around longer.
I agree, the Adobe SVG Viewer is the most advanced SVG viewer at this time. A pitty that Adobe bought Macromedia though. The SVG support in Dear Park Alpha is very promissing though, and so is the upcoming Renesis engine.
When I get a "this website works only in IE version X", I will try to change the user agent string in Firefox (User Agent Switcher). If it still doesn't work I usually write an email to the webmaster complaining about the problem with his site, and ask him for notification when he will have it fixed. If that notification never arrives, bad for the site, it just lost a visitor.
Yes, you are right. It is statistical noise when Firefox goes down by 0.64% according to a single source (NetApplications.com), and it is a great achievement when Firefox steadily increases its market share over a very long period of time and according to many different sources.
The statistics are provided by NetApplications.com.
Their numbers come from aggregating browser stats from all sites using their service -- hardly a statistically-valid sample of the web audience. Read more about it
here.
I have been using design patterns for some years now (in fact everybody who does OOP does, whether they know it or not), but I never had the patience to read a book on the subject. They were so boring and dull, and without the proper examples, I was usually forgeting everything anyway in a couple of days, even before I was applying it into a concrete design.
Now I got admitted into a Software Engineering MSc program, starting this autumn and I really felt I had to improve my design pattern skills this summer. So I started reading this great O'Reilly book De Lemming already told you about (yes, Head First Design Patterns). It is really amazing. Although it is very long, and covers a lot of ground, I never got bored while reading it. On the contrary, I had great time, laughing very often, and implementing every pattern myself in..... JavaScript (I don't use Java because it would be too easy, and would spoil all the fun:) ). Really an amazing book, I would recommend it to anyone who is serious about learning design patterns.
This was the case only until this book came out: Head First Design Patterns. Really an amazing book, I would recommend to anyone who is serious about learning design patterns.
Slashdot Mirror
OK. Only a little OT :)
This page then maybe needs a fix.
The RSS 3 Requirements Page: General RSS 3 Requirements:
6. The Standard should strive to remain as backwards compatible as possible with the RSS 2.0 standard
For what purpose is the RSS Version 3 standard necessary?
The 0.9x class of standards is outdated and underdocumented. The 2.0 class is highly underdocumented, filled with unnecessary features though lacking others which could be useful. The RSS 3 standard is supposed to extensively document the standard, to expand where expansion is needed and to remove unnecessary features.
Is any of you satisfied with the explanation that the world needs a new RSS standard because the other versions are not well documented? What on earth stops him (Jonathan Avidan) from documenting them properly?
So what? The RSS guys managed to release several incompatible versions, and this even without Microsoft's help.
The Standard should strive to remain as backwards compatible as possible with the RSS 2.0 standard
There is quite a big difference between striving to provide backwards compatibility, and actually obtaining it.
Why on earth would we need another (fourth) RSS version?
Also worth mentioning is that the Atom syndication standard, currently in development, is out of this standard's scope and does not concern it. Due to contradiction in structure, the standards cannot rely on one another, yet an implementing client should support both standards.
How about all five RSS 0.92, RSS 1.0, RSS 2.0, RSS 3.0 and of course ATOM. This will be really a joy for implementers.
You don't think Flash and SVG can live side by side?
Well, on way or the other they will have to live side by side. The question is whether their marketshares will become somehow comparable or not. Actually, nobody will complain for having Flash support in her/his browser, as long as there is also SVG support. And Opera and Firefox will hopefully have built-in SVG support soon enough.
For me personally, the prospect of SVG in the near future lies in non-animated interfaces - Application skins (go from bulky Media Player to slick Winamp with two clicks), faster loading of graphics-heavy web pages, building on previous work easily by checking the source of pages, getting away from non-XML syntax for advanced styling (CSS), and such.
None of these applications will be easy (or even possible) to use without a good SVG viewer.
Have you ever tried viewing the source of a Flash file?
Yes I did, and I also do know the advantages and disadvantages of both Flash and SVG. Nobody in this conversation tried to deny the technical merits of SVG. But for one technology to achieve widespread use, technical merit is never enough.
Yes, I like SVG too, and I would love to see more people using it. But this doesn't mean I will go blind and not notice its tiny market share or its very slow adoption rate. And these problems are very much agravated by the lack of complete viewers. You know, designing a complex XML vocabulary like SVG is much simpler than building the tools to actually use it.
SVG has to compete with semantically void images.
... we went through those pains, and probably will do so even more in the future. But we are doing this only with the hope that, one day, people will also be able to easily use our applications.
No. SVG has to compete with Flash. And the widespread adoption of Flash by both the commercial and open source (e.g., OSFlash, OpenLaszlo etc.) communities was caused by the fact that Flash is a good platform to develop for, and has a consistent and ubiqutous Flash Player. It has nothing to do with semantics (and it never will) or scaling or anything else. No sane company would target a platform that doesn't even have good viewer. Very few developers will go through the pains of building a serious SVG application if nobody can use it.
Well
If SVG was released when CSS was (i.e. ten years ago), maybe your argument would have made sense. You say that "SVG is the only way to separate the content of images from their presentation, and to make them properly scalable" and you are wrong. Flash has allowed this for many years now. No, it is not a standard, but it seems that nobody other than you and me cares about it. And, well ... why should they?
IT Marketing News - December 2000
Nobody has ever made a full implementation of CSS2, and it's very popular.
This is a very different story. CSS had to compete with unstructured HTML code full of font and color tags, and it was clearly a technically better solution (although complex). Everybody is using CSS because it is the only way to separate the content of a web page, from its presentation. And because CSS is extremely popular CSS2 has a clear road ahead.
The situation of SVG is very different. Macromedia Flash is already a very mature platform that already almost everything that SVG does now years ago and it did this in a very coherent way (they don't have to worry too much about interoperability). The Flash Player is installed on almost every networked computer, and it works the same everywhere. If SVG wants to have the smallest chance of replacing Flash it will have to match this. So full implementations of the SVG standard are not just nice extras, they are mandatory for the success of SVG.
Complete implementation? No. But pretty much every feature has been implemented and tested in some implementation as of the end of last year
The page was last updated on 2003/08/12 18:41:23, so it was published two years from now. The problem is that every feature has been implemented and tested in a different implementation. It would be really helpful to have complete implementation(s).
Not to knock the great work Inkscape has done, but it's not the most advanced. I would guess Adobe SVG Viewer is better as a viewer. It's definitely been around longer.
I agree, the Adobe SVG Viewer is the most advanced SVG viewer at this time. A pitty that Adobe bought Macromedia though. The SVG support in Dear Park Alpha is very promissing though, and so is the upcoming Renesis engine.
I really don't get it. How will an XForms implementation help SVG? Parent was complaining about the lack of complete SVG viewers.
You mean ... like this: Schnappi das kleine Krokodil (Original).mp3?
When I get a "this website works only in IE version X", I will try to change the user agent string in Firefox (User Agent Switcher). If it still doesn't work I usually write an email to the webmaster complaining about the problem with his site, and ask him for notification when he will have it fixed. If that notification never arrives, bad for the site, it just lost a visitor.
Yes, you are right. It is statistical noise when Firefox goes down by 0.64% according to a single source (NetApplications.com), and it is a great achievement when Firefox steadily increases its market share over a very long period of time and according to many different sources.
The statistics are provided by NetApplications.com. Their numbers come from aggregating browser stats from all sites using their service -- hardly a statistically-valid sample of the web audience. Read more about it here.
http://news.bbc.co.uk/1/hi/world/americas/4718579. stm#
... for automatically equilibrating drunk people.
I find the (girl on) cover pretty cute. What is wrong with not having a dull cover?
I have been using design patterns for some years now (in fact everybody who does OOP does, whether they know it or not), but I never had the patience to read a book on the subject. They were so boring and dull, and without the proper examples, I was usually forgeting everything anyway in a couple of days, even before I was applying it into a concrete design.
..... JavaScript (I don't use Java because it would be too easy, and would spoil all the fun :) ). Really an amazing book, I would recommend it to anyone who is serious about learning design patterns.
Now I got admitted into a Software Engineering MSc program, starting this autumn and I really felt I had to improve my design pattern skills this summer. So I started reading this great O'Reilly book De Lemming already told you about (yes, Head First Design Patterns). It is really amazing. Although it is very long, and covers a lot of ground, I never got bored while reading it. On the contrary, I had great time, laughing very often, and implementing every pattern myself in
This was the case only until this book came out: Head First Design Patterns. Really an amazing book, I would recommend to anyone who is serious about learning design patterns.