So you're saying you know for a fact that there are no patents covering anything in the ODF standard? If so why did Sun produce a convenant not to sue ODF developers?
Not so favourable to your argument. It basically says exactly the same thing I did, this is a battle between Microsoft and a bunch of companies competing against Microsoft for market dominance.
But really can you look yourself in the face and say this isn't a battle for commercial gain between Microsoft and Sun/IBM/Google?
The differences between the licensing of OpenXML and ODF is really about hair splitting about the only differences I can discern are, one was written by Microsoft and the other by Sun.
At the moment I would say Microsoft is almost looking like the party that is playing the most fairly. Read this...
Basically Microsoft are providing ODF support in Office, so where is the corresponding support for OpenXML in OpenOffice and Google's online Office suite?
The differences between Microsoft's proposed open standard OpenXML and IBM/Sun's ODF standard in terms of functionality they're virtually interchangable. It's the licensing of these standards that's the issue. Now you're all going to jump in and say that OpenXML is tainted because it is under a license written by Microsoft. You should also consider that ODF's license is written by SUN. The following analysis of OpenXML and makes comparisons of the licensing of OpenXML to ODF.
Microsoft's CNS is similar to a covenant issued by Sun Microsystems Inc.,
in September 2005, in respect of any patents that it holds in respect of the
Open Document Format ('ODF') for Office Applications (OpenDocument)
v1.0 Specification ('Sun's Covenant')15.
There are three qualifications detailed in the Microsoft CNS, which are also
present in Sun's Covenant and reflect standard industry practice.The first
is designed to protect Microsoft from the actions of others. It states that the
covenant will not apply where a person asserts or threatens to assert rights
against Microsoft.The second qualification concerns the scope of Microsoft
patents: it is designed to put users on notice that a conforming implementation
of the Schema may not include a patent claimed by Microsoft or, if the
conforming implementation does include such a patent, that the patent may
not be enforceable.The third qualification addresses the intellectual property
rights of others that any conforming implementation of the Schema may
contain. Microsoft is not in a position to protect users from any such third
party infringement.The second and third qualifications are designed to protect
Microsoft from any liability arising from the implementation of the Schema.
As such, neither impact on the 'safe harbour' users are given under the CNS
from any Microsoft enforcement action.
So basically it seems that the licensing issues surrounding ODF and OpenXML are pretty much equivalent. There are strings attached to both the ODF and OpenXML formats and those strings are basically there to stop third parties from being able to legally attack Microsoft or Sun.
As I see it this story is really about whether legislation is going to be passed that is prejudiced against Microsoft and formats they have created.
Microsoft 2007 formats are compatible with Office 2003, Office XP, and Office 2000, all you need to do is download and install this patch.
Microsoft has actually made a commendable effort in providing support for existing versions of office. The problems being referenced here have actually already been addressed. This fix comes not from Microsoft but from someone who has utilised the open framework that is Office 2007 to resolve the issue.
Office 2007 formats are basically zip files containing xml files all with schemas that have been submitted to the ECMA standards body. Combined with sdk and api inbuilt into the.NET framework Office 2007 has turned office into a very powerful development platform for document processing.
Anyone reacting as you've described I'm afraid is doing so as a result of total incompetence and complete ignorance.
I think migration to Office 2007 in the corporate world is going to be relatively swift (inspite of the support for previous versions of office offered by Microsoft). Migration to Office 2007 will occur because it is a great product that is more open and easy to extend and manipulate than any over version of office (as demonstrated in David Carlisle blog). It will also be a no brainer for any organisation using Sharepoint as it offers good integration with sharepoint.
Of course you're not getting rich, and I'm certainly not. But you can bet your ass that there are people out there literally making billions out of Iraq. Where do you think all this funding for Iraq goes to?
Well it's pretty simple it's going to a lot of companies and who profits from these companies?
Oil is being pumped out of Iraq every day, money for 15% of the oil that has been shipped from Iraq has simply disappeared. No one can account for it. Just google 'iraq corruption', you will see enough smoke to realise there's a pretty intense fire there. If you're still not convinced go check Haliburton's stock price in the last 6 years. If you think for one second that people are dying in Iraq today for any other reason than oil and money you are totally deluded.
I suggest you actually go to the middle east, India, or China, talk to an average joe, you'll soon understand what modern day enslavement is about and how money works to enslave people. Iraq is all about making a small minority of people a whole lot richer and making the rest of us relatively poorer. More for the conquerors, less for the non-conquerors, that is the true nature of conquest, plain nasty ruthless greed. It's very simple.
Anyhow getting back to the penatgon....
Here's a theory... have a look at your one dollar bills, hmm what's that pyramid doing there? And how about that washington monument, that seems a little familiar doesn't it?
Ummm just maybe that pentagon is a Freemason thing? Just a wild guess.
View source.... search for Urchin.... Every page on slashdot has a google analytics script that sends a cookie to Google uniquely people visiting the page (unless you have blocked it as I have done).
I'd say pretty much 90% of the web currently has Google javascript embedded in it. They know who you are, how often you surf the web, what pages you visit, how often you visit them etc etc etc.
The unbelieveable irony of people on Slashdot bitching about an imaginary technology that Microsoft doesn't have, whilst Google is collecting info about every person reading this article is quite incredible.
Everybody is using google analytics including slashdot.
Google already is tracking everybody through google anayltics and their search engine.
The irony of this attack on an imaginary Microsoft technology coming from Slashdot with Google analytics embedded in every page is really quite breath takingly MORONIC!
I think the only way anyone is going to settle the whole performance thing is to actually go off and do some performance and load testing with two systems using both methods. What you're saying (depending on the literature you read) sounds entirely plausible, however I think the proof is always in the pudding.
I have faith that stored procs are actually going to win if only by the barest margin simply because there's an obvious reduction in network traffic for large complex queries. Plus I have faith that stored procs compiled once on a central server by SQL server are actually going to perform better than queries compiled several times in code running on a VM on every client connecting to the server.
However I admit I really don't know what the outcome would be and I don't think you know either the only way to get half a clue would be to do performance tests.
For me performance is not the driving motivator for using stored procs, it is the extra layer of security, and the manageability of stored procs.
Yes one day I could be as good a developer as you... dare to dream.
My comment was obviously meant with humour. I collaborate with other developers all the time. I even go to user group meetings to get exposure to as many alternate views on development as possible.
And like most developers I prefer to work with new or next generation technology rather than working within the confines of some sort of time bubble from 10 years back due to the restrictions of some legacy system's architecture.
Stored procedures can also improve performance. Many tasks are implemented as a series of SQL statements. Conditional logic applied to the results of the first SQL statements determines which subsequent SQL statements are executed. If these SQL statements and conditional logic are written into a stored procedure, they become part of a single execution plan on the server
Basically I think it comes down to consistency. I don't like writting an application where one half of my T-SQL code is in the DB and the other half in my source code.
At the end of the day I find in just about every enterprise app there is at least one feature that requires a complex set of T-SQL instructions to be executed that have definite performance benefits when executed within a stored proc as opposed to parameterised queries executed from source code.
So for consistency and extensibility I always stick my T-SQL into the database, it also keeps the DB administrators happy.
Well the biggest clue I have about security is that you build it into every tier of your architecture. Sticking security in one place is not a security architecture, well OK it might be, but as far as security architecture goes it sux.
In my real world I don't come across many legacy apps that don't leverage stored procs. Stored procs for way longer than 5 or 6 years. They were officially made part of the SQL language in 1999 and they were unofficially around many many years before that.
I don't go round re-writting everything just for the sake of making it mine. In the real world you evaluate every application on a case by case basis. In the real world it is very often the case that the time required to add new features or fix existing features on badly written legacy app is less than the time required to re-write it with modern programming tools.
I also don't come across many jobs dealing with legacy apps, and the ones I do I tend to steer clear of. I prefer creating my own crap than dealing with somebody elses.
The whole parameterized query thing vs stored procs argument has been argued from the day the internet was born. Here's the arguments I would make for stored procs.
Most database engines also apply the exact same techniques to plain text queries. If the plain text queries are parameterized, then it works even better
Database engines more often than not will generate a whole new execution plan for plain text queries, it can also cause the execution plan cache to fill up more quickly, plus it opens you up to sql injection. Using plain text dynamic sql is just plain unforgiveable, if you really want to write your sql in your source code then you should use parametertized queries.
Microsoft's Transact-SQL is an absolutely horrible language that is very difficult to debug and had very poor error handling.
Most database engines takes advantage of store procedures to create a pre-prepared execution plan which is used to optimise and speed execution time. Visual Studio will work with any database with an ODBC connection. All Visual Studio gives you is a nice environment in which to extract sql scripts and check them into source control, you don't actually need Visual Studio, you can just use notepad and edit sql scripts and check them in and out of source control manually.
*sigh* I don't know what I was thinking to engage in any sort of serious technical discussion on slashdot.
Anyhow run off and write your apps without stored procs the "SQL Injection Scanner" market needs you and your dodgy code.
It is common practice with database development tools to update stored procs from sql scripts which are checked into source control systems. Microsoft has a whole verion of Visual Studio for this purpose.
Not using stored procs at all in your application is typically done by novice developers, it is not how an experienced professional works with a database.
Slashdot Mirror
That's total FUD.
l openxml_1.html
http://www.infoworld.com/article/06/12/04/HNnovel
http://www.dataviz.com/
OpenXML has/is being implemented by 3rd parties.
So you're saying you know for a fact that there are no patents covering anything in the ODF standard? If so why did Sun produce a convenant not to sue ODF developers?
Well it seems like I'm answering my own question...
l openxml_1.html
http://www.infoworld.com/article/06/12/04/HNnovel
Novell is supplying openxml support for OpenOffice.
Datavis already seems to provide support for OpenXML
http://www.dataviz.com/
So I guess some people have managed to decipher Microsoft's documentation.
The first link google, yahoo and live bring up...
/ 2007/05/odf_vs_openxml.html
f _vs_oxml
http://weblog.infoworld.com/realitycheck/archives
Not so favourable to your argument. It basically says exactly the same thing I did, this is a battle between Microsoft and a bunch of companies competing against Microsoft for market dominance.
The second link on google...
http://opendocumentfellowship.org/introduction/od
Is of course more favourable to your argument. Yet it seems the best they can come up with is that OpenXML isn't well supported yet.
But really can you look yourself in the face and say this isn't a battle for commercial gain between Microsoft and Sun/IBM/Google?
0 7/05-20UOFODFPR.mspx?rss_fdn=Press%20Releases
The differences between the licensing of OpenXML and ODF is really about hair splitting about the only differences I can discern are, one was written by Microsoft and the other by Sun.
At the moment I would say Microsoft is almost looking like the party that is playing the most fairly. Read this...
http://www.microsoft.com/presspass/press/2007/may
Basically Microsoft are providing ODF support in Office, so where is the corresponding support for OpenXML in OpenOffice and Google's online Office suite?
Why should ODF reguire legislation to be passed in order for it to be successful?
Would you know an open document format if it bit you on the butt?
Can you explain how the licensing of ODF better than Microsoft's OpenXML?
The differences between Microsoft's proposed open standard OpenXML and IBM/Sun's ODF standard in terms of functionality they're virtually interchangable. It's the licensing of these standards that's the issue. Now you're all going to jump in and say that OpenXML is tainted because it is under a license written by Microsoft. You should also consider that ODF's license is written by SUN. The following analysis of OpenXML and makes comparisons of the licensing of OpenXML to ODF.
8 -4E0D-B290-C836D5F70867/0/OpenXML.pdf
...states:
http://www.bakernet.com/NR/rdonlyres/CC54A6B6-79E
Microsoft's CNS is similar to a covenant issued by Sun Microsystems Inc., in September 2005, in respect of any patents that it holds in respect of the Open Document Format ('ODF') for Office Applications (OpenDocument) v1.0 Specification ('Sun's Covenant')15.
There are three qualifications detailed in the Microsoft CNS, which are also present in Sun's Covenant and reflect standard industry practice.The first is designed to protect Microsoft from the actions of others. It states that the covenant will not apply where a person asserts or threatens to assert rights against Microsoft.The second qualification concerns the scope of Microsoft patents: it is designed to put users on notice that a conforming implementation of the Schema may not include a patent claimed by Microsoft or, if the conforming implementation does include such a patent, that the patent may not be enforceable.The third qualification addresses the intellectual property rights of others that any conforming implementation of the Schema may contain. Microsoft is not in a position to protect users from any such third party infringement.The second and third qualifications are designed to protect Microsoft from any liability arising from the implementation of the Schema. As such, neither impact on the 'safe harbour' users are given under the CNS from any Microsoft enforcement action.
So basically it seems that the licensing issues surrounding ODF and OpenXML are pretty much equivalent. There are strings attached to both the ODF and OpenXML formats and those strings are basically there to stop third parties from being able to legally attack Microsoft or Sun.
As I see it this story is really about whether legislation is going to be passed that is prejudiced against Microsoft and formats they have created.
*Cough*
0 0w/
http://www.palm.com/us/products/smartphones/treo7
Palm?
Even palm are using Windows Mobile in preference to their own OS.
The Palm OS is history.
In which case if you're an Office 2007 user you would save to PDF (which is supported out of the box in Office 2007).
David Carlisle has made changes to omml2mml.xsl stylesheet supplied by Microsoft to fix the issue.
1 0C9F7F3!2029.entry
m athml-from-office-20007.html
http://bhandler.spaces.live.com/blog/cns!70F64BC9
http://dpcarlisle.blogspot.com/2007/04/xhtml-and-
What a total pile of twaddle...
.NET framework Office 2007 has turned office into a very powerful development platform for document processing.
Microsoft 2007 formats are compatible with Office 2003, Office XP, and Office 2000, all you need to do is download and install this patch.
Microsoft has actually made a commendable effort in providing support for existing versions of office. The problems being referenced here have actually already been addressed. This fix comes not from Microsoft but from someone who has utilised the open framework that is Office 2007 to resolve the issue.
Office 2007 formats are basically zip files containing xml files all with schemas that have been submitted to the ECMA standards body. Combined with sdk and api inbuilt into the
Anyone reacting as you've described I'm afraid is doing so as a result of total incompetence and complete ignorance.
I think migration to Office 2007 in the corporate world is going to be relatively swift (inspite of the support for previous versions of office offered by Microsoft). Migration to Office 2007 will occur because it is a great product that is more open and easy to extend and manipulate than any over version of office (as demonstrated in David Carlisle blog). It will also be a no brainer for any organisation using Sharepoint as it offers good integration with sharepoint.
Word 2007 allows you to save to PDF.
Who's we sucker ?
t -of-iraq-oil-output-missing/2007/05/13/11789950000 73.html
Of course you're not getting rich, and I'm certainly not. But you can bet your ass that there are people out there literally making billions out of Iraq. Where do you think all this funding for Iraq goes to?
Well it's pretty simple it's going to a lot of companies and who profits from these companies?
http://www.smh.com.au/news/world/up-to-15-per-cen
Oil is being pumped out of Iraq every day, money for 15% of the oil that has been shipped from Iraq has simply disappeared. No one can account for it. Just google 'iraq corruption', you will see enough smoke to realise there's a pretty intense fire there. If you're still not convinced go check Haliburton's stock price in the last 6 years. If you think for one second that people are dying in Iraq today for any other reason than oil and money you are totally deluded.
I suggest you actually go to the middle east, India, or China, talk to an average joe, you'll soon understand what modern day enslavement is about and how money works to enslave people. Iraq is all about making a small minority of people a whole lot richer and making the rest of us relatively poorer. More for the conquerors, less for the non-conquerors, that is the true nature of conquest, plain nasty ruthless greed. It's very simple.
Anyhow getting back to the penatgon....
Here's a theory... have a look at your one dollar bills, hmm what's that pyramid doing there? And how about that washington monument, that seems a little familiar doesn't it?
Ummm just maybe that pentagon is a Freemason thing? Just a wild guess.
View source.... search for Urchin.... Every page on slashdot has a google analytics script that sends a cookie to Google uniquely people visiting the page (unless you have blocked it as I have done).
I'd say pretty much 90% of the web currently has Google javascript embedded in it. They know who you are, how often you surf the web, what pages you visit, how often you visit them etc etc etc.
The unbelieveable irony of people on Slashdot bitching about an imaginary technology that Microsoft doesn't have, whilst Google is collecting info about every person reading this article is quite incredible.
Aaaah working on it? .... They've already done it.
Just do a view source and search for urchin.
Everybody is using google analytics including slashdot.
Google already is tracking everybody through google anayltics and their search engine.
The irony of this attack on an imaginary Microsoft technology coming from Slashdot with Google analytics embedded in every page is really quite breath takingly MORONIC!
I think the only way anyone is going to settle the whole performance thing is to actually go off and do some performance and load testing with two systems using both methods. What you're saying (depending on the literature you read) sounds entirely plausible, however I think the proof is always in the pudding.
I have faith that stored procs are actually going to win if only by the barest margin simply because there's an obvious reduction in network traffic for large complex queries. Plus I have faith that stored procs compiled once on a central server by SQL server are actually going to perform better than queries compiled several times in code running on a VM on every client connecting to the server.
However I admit I really don't know what the outcome would be and I don't think you know either the only way to get half a clue would be to do performance tests.
For me performance is not the driving motivator for using stored procs, it is the extra layer of security, and the manageability of stored procs.
Yes one day I could be as good a developer as you... dare to dream.
My comment was obviously meant with humour. I collaborate with other developers all the time. I even go to user group meetings to get exposure to as many alternate views on development as possible.
And like most developers I prefer to work with new or next generation technology rather than working within the confines of some sort of time bubble from 10 years back due to the restrictions of some legacy system's architecture.
Stored procedures can also improve performance. Many tasks are implemented as a series of SQL statements. Conditional logic applied to the results of the first SQL statements determines which subsequent SQL statements are executed. If these SQL statements and conditional logic are written into a stored procedure, they become part of a single execution plan on the server
( SQL.80).aspx
http://msdn2.microsoft.com/en-us/library/aa174792
Basically I think it comes down to consistency. I don't like writting an application where one half of my T-SQL code is in the DB and the other half in my source code.
At the end of the day I find in just about every enterprise app there is at least one feature that requires a complex set of T-SQL instructions to be executed that have definite performance benefits when executed within a stored proc as opposed to parameterised queries executed from source code.
So for consistency and extensibility I always stick my T-SQL into the database, it also keeps the DB administrators happy.
and... If your db is MS SQL Server use sp_executesql not EXEC
No clue?
Riiight...
Well the biggest clue I have about security is that you build it into every tier of your architecture. Sticking security in one place is not a security architecture, well OK it might be, but as far as security architecture goes it sux.
In my real world I don't come across many legacy apps that don't leverage stored procs. Stored procs for way longer than 5 or 6 years. They were officially made part of the SQL language in 1999 and they were unofficially around many many years before that.
I don't go round re-writting everything just for the sake of making it mine. In the real world you evaluate every application on a case by case basis. In the real world it is very often the case that the time required to add new features or fix existing features on badly written legacy app is less than the time required to re-write it with modern programming tools.
I also don't come across many jobs dealing with legacy apps, and the ones I do I tend to steer clear of. I prefer creating my own crap than dealing with somebody elses.
The whole parameterized query thing vs stored procs argument has been argued from the day the internet was born.
Here's the arguments I would make for stored procs.
Most database engines also apply the exact same techniques to plain text queries. If the plain text queries are parameterized, then it works even better
Database engines more often than not will generate a whole new execution plan for plain text queries, it can also cause the execution plan cache to fill up more quickly, plus it opens you up to sql injection. Using plain text dynamic sql is just plain unforgiveable, if you really want to write your sql in your source code then you should use parametertized queries.
Microsoft's Transact-SQL is an absolutely horrible language that is very difficult to debug and had very poor error handling.
Debugging stored procs in Visual Studio is easy. This of course is impossible to do with dynamic sql.
Most database engines takes advantage of store procedures to create a pre-prepared execution plan which is used to optimise and speed execution time. Visual Studio will work with any database with an ODBC connection. All Visual Studio gives you is a nice environment in which to extract sql scripts and check them into source control, you don't actually need Visual Studio, you can just use notepad and edit sql scripts and check them in and out of source control manually.
*sigh* I don't know what I was thinking to engage in any sort of serious technical discussion on slashdot.
Anyhow run off and write your apps without stored procs the "SQL Injection Scanner" market needs you and your dodgy code.
It is common practice with database development tools to update stored procs from sql scripts which are checked into source control systems. Microsoft has a whole verion of Visual Studio for this purpose.
Not using stored procs at all in your application is typically done by novice developers, it is not how an experienced professional works with a database.
SQL injection attacks target code in which sql statements are dynamically created.
e.g.
'select * from employees where fullName like ' + mySQLInjectedInputFromUser
where mySQLInjectedInputFromUser has been asssigned a value entered by the user:-
Fred Flinstone; GO; delete employees; GO