I remember when they introduced smartcards in France in the mi-80s, it was the only country in the world where card fraud was actually decreasing rather than increasing.
Today when you try to buy something with a swipe card over there, they look at you funny, and some merchant don't even know how to handle your magnetic card.
I wonder why, nearly 20 years later, smartcards are not more widely used elsewhere...
Was it because until recently, there was a French patent on the design (a guy called Jean Moreno is the inventor, and the patent is now expired).
Surely, the cost of implementation is less than that of credit card fraud?
RFID as a cash-only card is useful and very successful in places like Hong Kong where you can buy your paper, pay the bus or your cinema ticket, but credit card information should not be available from RFID as there is no way to control who has access to the card information and when.
Having said that, I suppose the card company has made its studies and deemed that while there is a risk of card info being stolen, it is probably no worse than the current scheme. It should be easy enough to confirm: the merchant fee should be lower or the same as with the good old swipe method.
In the FAQ, they also imply that any payment above $25 would require the card owner's signature, so the risk of fraud remains low, but still higher than with a smartcard I think.
...that could be of interest to everyone else too.
While its a good thing that the specification for dSVG be proposed as a candidate for a standard, it currently clearly isn't one and the only existing implementation relies on DTD and EcmaScripts that have been developed by Corel and are own and copyrighted by Corel.
It would be many moons before dSVG ever becomes a standard, if ever (I hope it will be though).
In the meantime, anyone wanting to use dSVG would either have to use Corel's scripts or rewrite the whole language implementation.
The latter clearly being a potential trouble for a burgeoning new language (everyone could have her own variation, especially as dSVG is far from being complete and stable in features), if Corel is serious about getting people to use dSVG (which I think they are), then they should release their implementation under an Open Source license.
It doesn't have to be the GLP which is too strict and may probably slow the adoption of dSVG in corporate environments, but something like the Artistic License would certainly ensure that people are free to use Corel's fine work without fear of getting in trouble.
Another question regarding the performance of dSVG: since it is yet another abstraction layer over what is already a fairly thick pile of interpreters, parsers and renderers, it's not fast.
By that I mean that long lists and complex interfaces take quite a bit of time to update. This makes me wonder about building complex applications, or even simple ones that display a lot of data in lists for instance
Do Corel have any plan to incorporate dSVG directly inside their plug-in? That would certainly save time (there are a lot of ecmascript files to be loaded and interpreted), and should make the interface more responsive.
Plus it would give Corel's plug-in and edge over the Adobe's, in the corporate world at least.
I think the choices that Corel do now are going to affect the adoption of dSVG very significantly, and I'm not talking about just commenting on the Specification itself, as good and promising a start as it may be.
I for one love the idea of being able to develop SVG applications.
While it's true that SVG currently need a plug-in, that its installation base is quite small compared to Flash (but most people installing Adobe Acrobat install the SVG plug-in without even noticing), the SVG specification is a W3 Standard, and it's easier to integrate with other Open Source tools on the server side.
I doubt that dSVG will initially appeal to a large public who won't see the point of it over Flash for multimedia applications, but it certain should appeal to people writing applications for the enterprise where it's easier to control what is installed on the users' machines.
dSVG could be a great cross-platform tool (while the GUI software that build applications runs only under Windows for now, SVG runs on any platform) and could actually be helpful in pushing companies to use SVG as a standard for web applications rather than rely on proprietary formats that are not easy to integrate with Open Source development tools or that will always be a couple of step behind the commercial implementations.
It must also be recognised that while the technology to build really powerful web application is there in IE, Mozilla, Opera and al, there are very few really interactive applications using those technologies, simply because there is not enough compatibility between the various standard implementations, and to work around those is too costly and difficult to manage well.
We end up with web sites that use only the lowest common denominator set of technology, with is not enough to build really powerful applicative environments. So in the end, all those powerful technologies are great showcases, but get barely used in the real world.
While Flash is not going away any time soon (it is likely that it will always remain big in multimedia environments), SVG has more potential for building rich, natural, intuitive and powerful GUIs that easily integrate with existing and well established server technologies, Open Source or not.
I always liked Corel and their tools. I've been a fan of CorelDraw since version 2, and I really like that they are the first one who understand the role that SVG will play in application building.
Adobe is surely the major pusher of the technology, but they haven't yet caught up on that idea that SVG can go way beyond chart applications and pretty graphics.
What was missing was a GUI toolkit, and dSVG is looking good to fill that role, so instead of whining that the tools don't yet work on Linux or that the ULEA is 3km long, let's focus a bit on the question at hand: have a look at the specification and help if we can.
I know I will try because I need these tools, and I think our community is about supporting and encouraging that kind of attitude from commercial companies.
In Europe, particularly in Belgium and France, both american comics and manga have a wide following, but there is a much larger reader base for other types of 'Bandes Dessinées': cartoons of all sorts that can be entertaining (the well known Asterix, Tintin for instance) as well as thought-provoking, very well written, complex and rich stories anchored in real life, history, politics, fantasy or sci-fi. Drawing styles follow very different and wider rules than comics and manga, from the hyper-realistic to the almost impressionistic.
I really find it a shame that the immense majority of this art form does not find its way into many other languages, I can assure you that the/. crowd would be hooked to the wonderful and intelligent stories of the 9th Art.
Slashdot Mirror
Today when you try to buy something with a swipe card over there, they look at you funny, and some merchant don't even know how to handle your magnetic card. I wonder why, nearly 20 years later, smartcards are not more widely used elsewhere...
Was it because until recently, there was a French patent on the design (a guy called Jean Moreno is the inventor, and the patent is now expired).
Surely, the cost of implementation is less than that of credit card fraud?
RFID as a cash-only card is useful and very successful in places like Hong Kong where you can buy your paper, pay the bus or your cinema ticket, but credit card information should not be available from RFID as there is no way to control who has access to the card information and when.
Having said that, I suppose the card company has made its studies and deemed that while there is a risk of card info being stolen, it is probably no worse than the current scheme. It should be easy enough to confirm: the merchant fee should be lower or the same as with the good old swipe method.
In the FAQ, they also imply that any payment above $25 would require the card owner's signature, so the risk of fraud remains low, but still higher than with a smartcard I think.
...that could be of interest to everyone else too.
While its a good thing that the specification for dSVG be proposed as a candidate for a standard, it currently clearly isn't one and the only existing implementation relies on DTD and EcmaScripts that have been developed by Corel and are own and copyrighted by Corel.
It would be many moons before dSVG ever becomes a standard, if ever (I hope it will be though).
In the meantime, anyone wanting to use dSVG would either have to use Corel's scripts or rewrite the whole language implementation.
The latter clearly being a potential trouble for a burgeoning new language (everyone could have her own variation, especially as dSVG is far from being complete and stable in features), if Corel is serious about getting people to use dSVG (which I think they are), then they should release their implementation under an Open Source license.
It doesn't have to be the GLP which is too strict and may probably slow the adoption of dSVG in corporate environments, but something like the Artistic License would certainly ensure that people are free to use Corel's fine work without fear of getting in trouble.
Another question regarding the performance of dSVG: since it is yet another abstraction layer over what is already a fairly thick pile of interpreters, parsers and renderers, it's not fast.
By that I mean that long lists and complex interfaces take quite a bit of time to update. This makes me wonder about building complex applications, or even simple ones that display a lot of data in lists for instance
Do Corel have any plan to incorporate dSVG directly inside their plug-in?
That would certainly save time (there are a lot of ecmascript files to be loaded and interpreted), and should make the interface more responsive.
Plus it would give Corel's plug-in and edge over the Adobe's, in the corporate world at least.
I think the choices that Corel do now are going to affect the adoption of dSVG very significantly, and I'm not talking about just commenting on the Specification itself, as good and promising a start as it may be.
CycnusI for one love the idea of being able to develop SVG applications.
While it's true that SVG currently need a plug-in, that its installation base is quite small compared to Flash (but most people installing Adobe Acrobat install the SVG plug-in without even noticing), the SVG specification is a W3 Standard, and it's easier to integrate with other Open Source tools on the server side.
I doubt that dSVG will initially appeal to a large public who won't see the point of it over Flash for multimedia applications, but it certain should appeal to people writing applications for the enterprise where it's easier to control what is installed on the users' machines.
dSVG could be a great cross-platform tool (while the GUI software that build applications runs only under Windows for now, SVG runs on any platform) and could actually be helpful in pushing companies to use SVG as a standard for web applications rather than rely on proprietary formats that are not easy to integrate with Open Source development tools or that will always be a couple of step behind the commercial implementations.
It must also be recognised that while the technology to build really powerful web application is there in IE, Mozilla, Opera and al, there are very few really interactive applications using those technologies, simply because there is not enough compatibility between the various standard implementations, and to work around those is too costly and difficult to manage well.
We end up with web sites that use only the lowest common denominator set of technology, with is not enough to build really powerful applicative environments. So in the end, all those powerful technologies are great showcases, but get barely used in the real world.
While Flash is not going away any time soon (it is likely that it will always remain big in multimedia environments), SVG has more potential for building rich, natural, intuitive and powerful GUIs that easily integrate with existing and well established server technologies, Open Source or not.
I always liked Corel and their tools. I've been a fan of CorelDraw since version 2, and I really like that they are the first one who understand the role that SVG will play in application building.
Adobe is surely the major pusher of the technology, but they haven't yet caught up on that idea that SVG can go way beyond chart applications and pretty graphics.
What was missing was a GUI toolkit, and dSVG is looking good to fill that role, so instead of whining that the tools don't yet work on Linux or that the ULEA is 3km long, let's focus a bit on the question at hand: have a look at the specification and help if we can.
I know I will try because I need these tools, and I think our community is about supporting and encouraging that kind of attitude from commercial companies.
In Europe, particularly in Belgium and France, both american comics and manga have a wide following, but there is a much larger reader base for other types of 'Bandes Dessinées': cartoons of all sorts that can be entertaining (the well known Asterix, Tintin for instance) as well as thought-provoking, very well written, complex and rich stories anchored in real life, history, politics, fantasy or sci-fi. /. crowd would be hooked to the wonderful and intelligent stories of the 9th Art.
Drawing styles follow very different and wider rules than comics and manga, from the hyper-realistic to the almost impressionistic.
I really find it a shame that the immense majority of this art form does not find its way into many other languages, I can assure you that the