March 31, 2005

Google Search Enhanced for Firefox

Google Search Enhanced for Firefox - MozillaZine Talkback

Google Blog is reporting that Google is now faster on Firefox and Gecko-based browsers. Google has started using prefetching to start downloading top results even before the user clicks on them. This allows the user to view search results faster. Prefetching is not available on Internet Explorer and other non-mozilla browsers.

One question, one comment:

[UPDATE] - I feel better after reading the FAQ on prefetch that I have the ability to tell Google "Thanks, but no thanks." That still leaves the "Mozilla-based only" which can be answered by the fact that, at present time, only Mozilla supports this capability (and my initial "unresearched" understanding was in fact incorrect.) This now leaves the question: If a platform provides a non-standards-based feature should you take advantage of it (critics of MS in the past used this as one of the reasons MS was evil) or simply ignore it until such time as all browsers are capable of it? Personally I'm all for taking advantage of what a platform has to offer... I wonder though if the MS critics of the past will suddenly change their tune and applaud Google for "taking a stand." This also raises one other question: If it will appear like a "declaration of war" against Microsoft, even if its not, do you take the risk and deliver the feature? Hmmmm... thats a tough one to answer. While I want to applaud Google for having the guts I fear what the outcome will be because it. Again, time will tell....

Question: Is there anybody on this planet who is either surprised by this and even further wondering whats taken so long for something like this to take place?

Comment: So what you're saying is Google is now a proprietary platform? To get the benefit of "prefetching" I can't use IE and instead have to use Mozilla or a Mozilla-based browser? Ok, not a problem... while using Firefox and desirous to do a search (and need the pages I click to load faster, something I assume is done by caching the latest copy of a web-page on your server and then feeding it to the client via your server/bandwidth which is obviously going to be considerably faster on average [Hmmm... I seem to remember Tim Bray taking notice to the fact that Google was forcing a "200" response after first receiving a "304" through some search engine crawler voodoo... I think this fits quite nicely as the assumed answer to the statement made in the last paragraph] I'll use Google. When using IE and desirous to do a search I'll use MSN Search. Problem solved. Besides, MSN Search kicks Google's A$$ anyway so this just makes the task of weening myself off Google that much easier. While I can appreciate having faster download times for the pages I access I would be surprised if Microsoft doesn't follow suit. I can't imagine it would take much effort (if not already in the works)... have you seen how quickly, often, and as such accurately they have a cached version of any given site available to look at via the download result "cache" link? [UPDATE: I can't speak for anyone else but I'm not so sure I want my sites being cached and served "by proxy" via Googles server farm... With the recent "SmartTags" clone fiasco whats to say they won't be offering up "Google Enhanced" versions of my pages... I purposely don't put ads on my pages and sure as heck don't want Google taking the liberty to serve them up for me instead. Do I honesly believe that would happen... no. But after last months ordeal coupled with this (they already use ad bots to parse Gmail and serve up, with surprising accuracy, ads related to the content) I'm just not so sure I want to exclude this as a possibly quite yet.]

Actually, I lied... I have one more question... This ones to Google directly:

Do you honestly feel grown up enough to make such a profound statement as to not support IE for a service which, to be honest, I havent even played with but from the sound of it I'm wondering why I should care? The results are fast enough for most sites. How much faster do I need them to be? Or am I not understanding what the technology actually does? Still, even if it provides something completely and totally incredible that will be portrayed as something I just can't live without please tell me why I absolutely have to be using Firefox (or another Mozilla-based browser?) I probably use IE 30-40% of the time and Firefox the rest but if IE7 provides anything close to what I expect it will I doubt that "prefetching" is going to be the decisive factor for me to forego IE7 which I can only assume (speaking from a developers perspective) is flat out going to kick some serious a$$.

This is a bold statement Google. Adam Bosworth or no Adam Bosworth I'm just not sure its the smartest decision you've made. Having one of the most brilliant computer scientists/developers this generation has ever known doesn't suddenly give you the ability to take an attitude against the behemouth that is Microsoft, *THE* most successful software company the world has ever known, now in its 30th year of proving time after time that they have what it takes to take on whomever is desirous to challenge them. Are you sure your 5 years-old child-based frame is ready to take on a 30 years-old full grown adult frame? Oh wait, sorry, you're 5 1/2 now arent you? Or maybe youre nearing your 6th BDay! 7th??? Wow you must be getting close to losing your front teeth now, aren't you!!! Oh wait, I guess you are reaching the stage where the cuteness factor wears off anyway so I guess this is to be expected.

I think what perplexes me the most is I'm beginning to notice a trend in which you are showcasing a bit of a "We're Google, everbody loves us so who gives a f---!" kind of attitude. I promise people do care. And like it or not Microsoft is a *BIG* company who doesn't take kindly to declarations of war, which, like it or not, this announcement is exactly what it will be construed as. You sure you're ready for the battle? I have my doubts that you are and it makes me sad because you are doing some pretty cool things served up by some pretty amazing talent.

Only time can tell and if it turns out I was wrong on this I'll be the first to admit it. Here's the thing though... I don't want to be right! I just can't help but look at this and wonder what on earth you are thinking?! This is practically taking a can of black and red spray paint, painting a bullseye on your chest (bigger than the one thats already there I should add), handing Bill a paint ball gun and letting him stand as close to you as he wants while he unloads the chamber. In fact I wouldnt doubt it if, while you are gasping for breath and holding up you're index finger as if to say "hold on... wait, I wasn't quite ready... give me a second... that wasn't fair, I need a do-over..." Bill simply reloads the chamber, turns the paint-ball gun back in your direction and has another go round.

Its a bold move Google. Good luck! I'd cheer you on but, to be honest, I really don't want to be anywhere near the playing field when this game begins, much less ends. Still, go get 'em Tiger, ROAR!!!

Posted by m.david at 04:31 AM | Comments (0) | TrackBack

March 30, 2005

In follow-up to the DataDirect XQuery Study

I recently received an email from Larry Kim of DataDirect asking if I wouldnt mind making a post regarding his recent study covering the usage of XQuery amongst a study sample set of 550 developers. Larry is undoubtedly aware of my "history" of posts regarding XQuery so in doing so I get the impression that he feels confident about these numbers and is ready and able to answer the questions of the community in regards to this report. While I undoubtedly have my own opinions on the matter I think Elliotte Rusty Harold, Dimitre Novatchev, and Mike Champion have followed up the post to the list quite nicely so I plan to take a slightly different approach in this posting, instead offering up some advice to the XQuery community by way of some analogies. But first, a summary of the XQuery study (a press release style overview can be downloaded here):

"We found that 52% of the 550 software professionals surveyed were already using XQuery -- with another 33% saying that they plan to use XQuery in the next 12 months!"

and then the question:

"Should XSLT fans be concerned?"

Ummmmmm.... do you want me to be honest or cover it with some sugar to make it easier to swallow? Times up! No sugar for you! ;) The answer...

Ummmmmm.... No. In fact if anything this should be more worrysome from the XQuery crowd as if these numbers don't pan out or seem at all "channeled and chiseled" it will cause wonder as to why the need if XQuery is all that it claims itself to be.

Actuality instead of providing criticism of this post I think the bigger need exists in providing an opportunity for DataDirect to quantify their numbers
while at the same time looking to real world projects such as Bruce D'Arcus and his XBiblio/Citeproc (of which I have joined the dev-team for further development of his existing code-base into other realms, domains, and applications (which I believe are actually the same thing depending on what generation you subscribe your hacker "slang" to :) to better understand how the development world is
either using, plans to use, or at very least perceives the space in
which XQuery fits into. If XQuery can be successfully used in ways
that maybe haven't been considered then it seems this should be the
task of DataDirect or any other company planning to provide products
to fill the assumed market need. Code speaks louder than marketing
numbers as its the code that is more difficult to counter, as long as
the code is solid and difficult, if possible at all, to counter with
the equivalent or better XSLT 2.0-based solution.

Without a doubt theres a business in XQuery. The only concern I have
is that too much time and money will be spent 'hyping' the media and
not enough time feeding the development community code. Doing this (hyping)
has already cast a pretty dark shadow over XQuery as the attempts have
come in direct attack of XSLT 2.0 in which a community, nay, an army
of XSLT developers have already banded together to take up arms
against. If I can suggest one thing in moving forward using a common
analogy:

"Keep your friends close, and your enemies closer."

To me the "enemies" from the perspective of XQuery are perceived to
live in the xsl namespace. In reality XQuery has become its own worst
enemy and really should be keeping tabs on its own a$$ if this analogy
is to be taken literally. And it really should! It would be a shame
to see XQuery die before its even born as its a good and necessary
language that fits well into the space of querying XML data stores
using a syntax similar to that of SQL such that SQL developers and/or
developers coming from a heavy procedural background can simply make a
few syntactical adjustments to then add XQuery to their areas of
language expertise.

Whether or not the "better than XSLT" claims have any real substance
taking this stance has consistantly brought opposition and at this
stage of the game opposition is not something to be sought after.
There is a bottomline that now exists in the XQuery realm and,
borrowing from a slightly modified Jerry Maguire, "Show Me The Code!"
should become the XQuery mantra from now until Tim Berners-Lee extends
his status of "Sir" to annoint "Sir XPath 2.0, Sir XSLT 2.0, and Sir
XQuery 1.0", sending them on their way into the battle of providing
XML Transformation, Query, and Path-based Referencing services to
version 2.0 of the WorldWideWeb. If seen as a team, Sir XQuery will
live on to fight many-a-good battles and be seen as a hero among many.
If seen as competition Sir XPath 2.0, taking loyalty to the family
birthright, will simply step aside and let Sir XSLT 2.0 take things
into his own hands providing only sparse details as to what "really"
happened out their in the battlefield claiming "its just too hard to
talk about... He was such a good and brave Knight that Sir
XQu-er-sniff, sniff Sir XQu-ahwahhahhahaaaaahhhhhahaahhh" as he
projects his sorry by wailing into tears, unable to say the complete
name of his "good ol' chum", providing a performance greater than any
other Oscar winner from years past has ever performed. The story
continues... "No one really understood why Sir XSLT 2.0 was often
heard chanting "Boom Boom Chee. Boom Boom Chee, We Will, We Will, Rock
You! Chee, Boom Boom Chee" while Sir XPath 2.0 bursts into laughter
each and every time, as if almost on que, but most definitely right on
the path. (ok, that one was officially a little too cheezy :)

I think their is some opportunity here to really take advantage of
this situation an put a really positive spin back into the XQuery
namespace. I just really hope thats what happens and not the opposite
as:

"I've paid my dues
Time after time
I've done my sentence
But committed no crime
And bad mistakes
I've made a few
I've had my share of sand
Kicked in my face
But I've come through

And we mean to go on and on and on and on

We are the champions - my friends
And we'll keep on fighting
Till the end
We are the champions
We are the champions
No time for losers
'Cause we are the champions of the World"(:WideWeb:)

... will quickly become part of the theme music to "The Legend of
XQuery" as it is told to our future hacking sons and daughters to
scare them into the well formed ways of the code (scare tactics are
necessary to ensure no one ever strays from the true and real path to
coding happiness -- Hey, if M. Night Shyamalan can get away with an
entire movie based on this premise then M. David Peterson should at
least get to keep his one little sentence, right? :D Did I just
reference myself in Third person? Oh hell, thatll never happen again,
I promise!

Cheers :)

[1] >> This quote seems to either come from the same study, or in fact this statement is really the base in which the marketing department and/or public relations team did what they are paid to do and that is find the very best way they can spin what they are given into something with marketing "flash" that will ultimatelly sell more product without binding yourself to flat out lies to do it.

To be honest I don't think there is anything contained in any of this that suggests DataDirect has done anything beyond adding some positioning flash to help make their up and coming XQuery product more marketable. I for one can not point fingers as I just as much if not more am guilting of finding and using catch phrases and keywords with a bit more "zing" to the senses to help drive home a point which in this case seems to be that developers are interested in XQuery and in fact they are interested to the point that 50-some% of XML-specific developers have already started using it in one form or another (You can add me to that list as there are most certainly times I have chosen to use XQuery if not for the fact that in that particular case an XQuery solution seemed easier but quite possibly because I simply wanted to learn XQuery and the problem seemed well suited to aid in this department.) If I havent stated my true position on XQuery strong enough in the past then let me try again. I like XQuery. It solves a lot the verbosity issues of XSLT and brings another functional-like language to the XML development world and above all I am a functional language proponent first, XSLT filling my functional XML programming slot. But this list also contains LISP/Scheme from an old school fundamentals perspective and projects like F# and to some degree COmega from an "on my list of high instensity learning projects", although there are certainly others.

In the end I think DataDirect hasnt commited the party foul we may have first thought they did and even if it turns out that they have overstepped a bit there is always the "golden rule" that fixes all party fouls... at least till the next occurence: Get us all drunk at the next conference and take pictures to then later blackmail us with ;)

Theres also another way to let things slide a bit:

Build killer products... They have. I'm happy.

Posted by m.david at 12:33 AM | Comments (0) | TrackBack

March 28, 2005

Pray

MSNBC - Tsunami alerts follow 8.2 quake near Sumatra

Posted by m.david at 09:39 PM | Comments (0) | TrackBack

March 27, 2005

Deep Thoughts by M. David

I think someone could make a million dollar business via licensing and subsequently creating a myriad of SWAG emblazened with the slogan:

"Lutz Roeder is my Co-Pilot"

Posted by m.david at 06:12 AM | Comments (2) | TrackBack

March 23, 2005

Its Official > I am the new King of Verbosity!

In a recent email thread between Kurt Cagle and myself he started his last response with:

"I'm beginning to think that you are capable of generating even more text than I am, and I thought I was the king of verbosity ]]>!"

Thats right folks! The torch has been passed from the originator of the 10,000 word blog posting himself... I am the new "King of Verbosity"!

Wait, thats a good thing, right? Hmmmmm... Did I just get sucker punched on this one? Well, sucker punched or not, the fact still remains... I'm the new King of Verbosity!!!

As a side note, I owe Bruce D'Arcus an entire day of dev work on the XBiblio/Citeproc project and today my friends is officially that day. As such I won't be available in email until late afternoon at best so please keep this in mind if you send me a personal note. The side-effect to this fact is that the result of todays dev work should allow for an easily portable ASP.NET-based Web Service app based on Saxon.NET for providing remote transformation services to client machines so stay tuned for links to the source.

Cheers :)

Posted by m.david at 01:39 PM | Comments (0) | TrackBack

March 22, 2005

In the muddy middle of all that is eXtensible, Queriable, and *ABOVE ALL* Transformable there is an unsung hero that nevers seems to get any credit

While in their own right there are many unsung hero's in the world of XML software development languages and while there are many individuals deserved of extensive praise I am speaking more to a specific technology, a workhorse who's expectations amount to 80% of XQuery's workload (what can you expect from an attempt to hack a together a couple "custom" macros and call it a programming language (I'm ready for ya... comon' -- showme whatcha working with... :D)) and is the pure and fundamental foundation of XSLT 2.0, as well as the built-in language standard for nearly every other technology that implements any sort of XML referencing functionality (speaking to XPath 1.0 in the now, and 2.0 as the uncontested winner from here on out.) I think I've already said enough to find myself the object of every XQuery lovers affection for days to come so instead of blabbering anymore I am simply going to state that I am officially deeming March 22nd, 2005 as XPath 2.0 Day here on ]]>

Thank you XPath 2.0. We couldn't do any of this without you!

Posted by m.david at 06:50 AM | Comments (0) | TrackBack

Interesting Microsoft Research Projects to Take Note Of

I spent nearly an entire month hinting towards the importance of paying attention to langauges like COmega,F#, and to Aspect-Oriented Programming methodologies. Of course its not like I am any sort of prophet or am privy to knowledge that no one else has access to. In fact the reality of the matter is learning about the future of software development languages requires nothing more than the ability to type resarch.microsoft.com or lambda-the-ultimate.org into your browsers address bar and hit enter.

Earlier today I was practicing the first of these addresses and was happy to discover that even after all these years ( I am 33 years old you realize! ;) I still have the touch... To showcase some of the projects that I found most interesting I share with you the following project names and descriptions as found on the download page of Microsoft Research.

AbsIL SDK for .NET Framework

Abstract IL an SDK for manipulating .NET Framework files and binaries. You can use this release from any .NET programming language, though it is best used from F#, or the OCaml language. With it you can access the contents of .NET binaries at a high-level, avoiding the details of the binary format. Abstract IL has been used for a compiler (F#), a static analysis tool looking analyzing code access security and an aspect-oriented programming project. Please visit the AbsIL SDK for .NET Framework web site for more information.

---
Ok, you're right, a little too obvious and well known...
---

AsmL for Microsoft .NET

AsmL is an industrial-strength executable specification language. It can be used at any stage of the programming process: design, coding, or testing. It is fully integrated into the Microsoft .NET environment: AsmL models can interoperate with any other .NET assembly, no matter what source language it is written in. AsmL uses XML and Word for literate specifications. Please visit the AsmL for Microsoft .NET web site for more information.

---
Again, obvious, well known, nothing here to see that you probably haven't glanced through before (don't let that cause you to not take heed in what the above description suggests.
---

CamWebSIM

CamWebSIM is a small quasi-HTTP server on a GSM SIM based on Microsoft Windows for Smart Cards. By making the SIM accessible over HTTP, the phone and the SIM become a personal security server in the Internet that is based on the GSM trust model. The code consists of 3 parts: 1) Code on the SIM in Visual Basic 2) Gateway code in Python 3) HTML and CGI access code Please visit the CamWebSIM web site for more information.

---

A web cam research project... Blaahhh! What is this world coming to if we are spinning our wheels research web ca,,, hold up, wait... Let me read the description again... quasi-HTTP server... blah, blah, blah, MS Windows... blahh, Smart Cards, yada, yada, YAWN, yada, SIM accessible over HTTP, the phone and the SIM become a personal security sever in (on? or maybe in... typo, or no typo thats a keyword I think needs some attention).... more Internet blah, blah, GSM trust model... Hmmmm.... Code on SIM in VB (yippee, my 4 year old son will be Oh so.,... oh, sorry, I didnt mean to suggest that... nevermind... ;) blah, Gateway code in Python... wait, what? MS Research does Python... WAIT ONE SECOND!!!! Since when have MS and Python had anything to do with each other??? Well, I guess there is that whole Socorro County thing to consider... and whats this "HTML and CGI access code" crap... Hmmmmm... theres something in this project thats not as apparent as I would like it to be, but its now got my official attention...
---

Disolver: the Distributed Constraint Solver

Disolver is a constraint-based optimization engine. It relies on an extended Constraint Programming paradigm which seamlessly integrates local search. It is especially designed to run in distributed/parallel settings and comes out as a C++ library. Disolver is the first building suite devoted to combinatorial problem solving in distributed and Grid-like infrastructures. Since we cannot redistribute the third party component used to perform message passing operations, this version of the solver is limited to sequential exploration. Please visit the Disolver: the Distributed Constraint Solver web site for more information.
---
Uhhhh... yeah, I'd pay attention to this one too...
---

F# Compiler

(Click the link above to download) F# is an variant of the ML programming language for .NET and has a core language that is similar to that of OCaml. It is a mixed functional/imperative programming language which is excellent for medium-advanced programmers and for teaching. In addition, you can access hundreds of .NET libraries using F#, and the F# code you write can be accessed from C# and other .NET languages. This release of F# includes a 'F# for Visual Studio', which provides interactive syntax highlighting, parsing, typechecking and intellisense for F# code inside Visual Studio 2003 and Visual Studio 2005 Beta 1. Please visit the F# Compiler web site for more information.
---
Nothing too much can be said here but based on my last comments and my subsequent motherboard frying episode I'll leave as is... for now...
---

Functional Reactive Animation

Fran is a Haskell library (or "embedded language") for interactive animations with 2D and 3D graphics and sound. Please visit the Functional Reactive Animation web site for more information.
---
Note to self (and anyone else reading this) PAY ATTENTION!!!
---

Gyro: Generics for the SSCLI

Gyro is a set of files that convert an existing installation of the Microsoft Shared Source CLI 1.0 to support generic type definitions and generic methods. These generic constructs take types as parameters, and are primarily intended to better support typed containers such as lists, stacks, and dictionaries. Microsoft's research work on generics is an ongoing project. This release is intended to allow you to familiarise yourself with the current state of the research, and to provide feedback where appropriate. Certain aspects of the design of generics for the SSCLI will change in future releases. Please visit the Gyro: Generics for the SSCLI web site for more information.
---
Ok, this is a good stopping point... If I don't stop now I never will so I will simply say that this is something that I personally plan to pay some serious study time to...
---

Note: To gain the actual links to these projects please visit the Microsoft Research Download area.

Cheers :)

Posted by m.david at 02:58 AM | Comments (0) | TrackBack

March 18, 2005

Saxon.NET 1.0 RC1 now available for download

Saxon.NET 1.0 RC1 is now available for download at:

http://www.saxondotnet.org/saxon.net/downloads/Saxon.NET-1.0-RC1.zip

[UPDATE: All .NET assemblies in this release have been properly signed]

There are still a few things I need to add to this, most importantly a URI caching such that namespace URI's will be able to access the base URI of there containing document. This doesn't cause any serious problems as far as usage and performance is concerned but is a necessary piece to ensure complete compliance to the W3C spec and to stay in sync with the latest Saxon release. This will be made available in RC2 after I am confident the community has had time to add the beneifit of their own tests to the mix and as such reported any showstoppers that would warrant extended bug bashing/development work.

This release is based on the latest 8.3(Basic) Saxon bits including all released code patches Dr. Micheal Kay has made available via the Saxon-Help mailing list. This build has been run through a battery of conformance tests and beyond warnings thrown (commandline only) when extended namespaces are used has passed with flying colors. This includes the testing that Dimitre Novatchev has been doing with his latest FXSL library for XSLT 2.0.

Thanks to everyone who has helped make this Release Candidate possible, specifically Dr. Micheal Kay for obvious reasons, Jeroen Frijters for his development of the IKVM.NET project, and Dimitre Novatchev for adding Saxon.NET as part of his ongoing test routines of the FXSL library which has proven beyond any reasonable doubt that Saxon.NET is ready to take on the XSLT 2.0, XPath 2.0, and XQuery 1.0 needs of the .NET development community.

Cheers to you all :)

[UPDATE: I am currently developing examples on how to implement extension functions via C# as well as the full extended documentation such that anything that is different than the usage contained in Saxon can be easily referenced both online and via a downloadble PDF). As soon as these become available I will post a link.]

Posted by m.david at 06:11 PM | Comments (4) | TrackBack

per my latest post to XSL-List | Addition of [[Namespace:reference]] to XSLTWiki

As I just posted to XSL-List I wanted to quickly let you all know that I just created a [[Namespace:reference]] entry on XSLTWiki.com as a place for the community to both keep updated and use a reference for Namespace:URI combinations for each released specification and working draft of XSLT, XPath, XQuery, and other commonly used specifications. As I am sure we have all painfully discovered when dealing with recently updated working drafts (as opposed to Recommended specs in which the namespace:uri combo's become solidified) we find ourselves having to update our stylesheets with the new values, something that can prove to be a real pain when trying to locate this information in a hurry.

Hopefully this will become something that we can all count on to be up-to-date given that the community as a whole can take on this responsibilty and as such make someones job as the W3C a little less stressful :)

Cheers :)

Posted by m.david at 05:18 PM | Comments (0) | TrackBack

March 16, 2005

Announcing the Saxon.NET 1.0 (Saxon-B 8.3 based) RC1 and Saxon# project - A true C# port of the Saxon source

I am pleased to announced two things. One is that through the ongoing efforts of Dimitre Novatchev and his FXSL project he uncovered a nasty Saxon.NET bug in which he reported (as always, Thanks Dimitre!) and I have since been able to spend the necessary time to locate, squash, and bring the final few details to order such that after being verified by Dimitre (so far so good... no doubt if one exists Dimitre will find it and let me know :) and with a successful run through a battery of tests I am working on at the moment the Saxon.NET project will have reached a 1.0 Release Candidate milestone (current base stems from the Saxon 8.3 source) signaling the very real possiblity that support for XSLT 2.0, XPath 2.0, and XQuery 1.0 in their current WD status will be made available in a 1.0 released product to developers of the .NET platform in the very near future.

For those interested I have checked all the source and compiled assemblies into Subversion which can be accessed for viewing at http://source.x2x2x.org/svn/x2x2x/saxon.net/0.1.8.3 and checked out anounymously using the same URI from a Subversion client. At the moment this is not signed but will be by weeks end when, if all goes well, I will make an official Saxon.NET 1.0 RC1 announcement.

It is my understanding that at the moment Don "DonXML" Demsak is pulling things together from the point of view of the XML-MVP community and through recent activitee in the group it is my understanding that other team members plan to get involved in taking Saxon.NET to the next level, something I am truly grateful for and thank everyone in advance for all the efforts they plan to put forth in this regard.

With this in mind and with the precursor that I will continue to provide development effort and support as needed for the Saxon.NET 1.0 release (as well as a few more sample apps I am working on and an extended documentation to cover what is not covered via Dr. Kay already) a path will have been cleared in which I will be filling with a "from-scratch" effort to port Saxon to a complete and total C# base, built around a pure .NET-based foundation. While I don't want to give the impression that I plan to move away from Saxon.NET (it seems that with recent activity in the group a lot less of my time will be required though) this new effort, labeled Saxon#, is something I will be working on from a solo perspective as I feel based on a "Heads down" effort I will be able to quickly deliver Saxon# and as such the community will have two complete Saxon-based XSLT 2.0, XPath 2.0, and XQuery 1.0 processors to work from. If you are scratching your head wondering why go to all the effort a quick view of the Saxon.NET project on Subversion will showcase the fact that Saxon.NET is built around a Java-based foundation which is compiled (after a combination of hacks against the base Saxon source to force the compiled assembly into proper File handling submission) using the IKVMC compiler from Jeroen Frijters IKVM.NET project. As such your existing Java project that makes calls directly to Saxon can now immediatelly be compiled and run on top of the .NET platform using Saxon.NET to handle the XSLT2/XPath2/XQuery processing. If theres is a better example of pure platform interoperabilty (you can do the same coming the other direction using a C#, VB.NET. *.NET codebase to make calls to the Java platform and Saxon Java source. Thats right! You can leave your SOAP REST'ing in the bath water from now on as whe needs WS-* when you have IKVM? (I just made like 470,000 enemies in one statement! Wont be the first time...) Ok, if you plan on making calls to remote applications (450,000 of you are now back, the other 20,000 never liked me anyway... ;) or something rediculous like that (lost another 50,000 on that one) then maybe I can see jumping back into the water for a quick swim (... 1.. no, nevermind) but for bouncing back and forth between Java and .NET on the same machine I doubt you will find something easier than simply adding "using java.io.FileStream;" or "import cli.System.IO.*;" (obviusly there are a million more examples of files that can be inter-swapped) to the top of your C# or Java files respectively (youll need to add the references but if I need to tell you this then I doubt you even know what I am talking about right now... its ok, go back to sleep... I'll be more quiet next time...).

So now with this said then the obvious benefit to a pure .NET foundation and a C# source is that you are taking advantage of all that .NET has to offer and not having to deal with using awkward intermingling of platform specific code (you will find a balance between what you can import and what must be called using the full classpath or namespace reference as there are obviously a TON of crashes that will take place with common things like cli.System.IO.xxx and java.io.xxx) while also gaining (or better said "not losing") some performance in the double translation that takes place via the IKVM.NET solution. Actually the performance loss isnt all taht much usually but enough to justify the port effort without even bringing the native class library into the equation... another obvious win...

With that I am heading back to the grindstone... have a great day!!! :D

Posted by m.david at 07:29 AM | Comments (0) | TrackBack

March 14, 2005

As promised in my last comment I am promoting J. David Eisenbergs books in thanks for listening to the concerns of his readers

As I mentioned in my follow-up comment to J. David Eisenberg's comments I am promoting his SVG Essentials and OpenOffice.org XML Essentials(a work in progress) titles as a thank you for paying attention to the concerns of his readers. I want to also thank Simon St. Laurent and his obvious connection to XML.com for following-up with comments as well. Its obvious to me that David, Simon, and XML.com are concerned with the content in which they produce and publish and while we may all differ in opinions as we stand from certain vantage points its nice to see that this doesnt keep us from trying to understand one another.

Cheers to you all :)

Posted by m.david at 07:24 PM | Comments (0) | TrackBack

March 13, 2005

Update on "XQuery 1.0 vs. XSLT 1.0" post..

I have received several good comments in both email and directly on this blog regarding my XQuery vs. XSLT 1.0 post from a few days ago. I've been away from my computer for the last 24 hours so I only just got to approving the most recent comment from Simon St. Laurent. He brought out a good point of which I wanted to make a little more public and then extend a few thoughts from. His comment:

[UPDATE: Dimitre Novatchev has followed-up Simon's comments with a very good point in that he doesn't know of one single case in which an XSLT developer has stated they plan to skip over XSLT 2.0 and move directly to XQuery. For what its worth, neither have I >> well, until just now when Simon stated this to be his intention. While Simon's point is still valid for those who have the same feelings he does I wonder how many others who have gone through the rough-and-tumble of learning XSLT 1.0 plan to move to XQuery once it becomes more readily supported. Anyone care to speak out?]

I think you're over-reacting pretty strangely. A lot of people are looking to move directly from XSLT 1.0 to XQuery, and I'm not sure that an XSLT 2.0 to XQuery comparison would be useful for that large case.

Apples to apples is great, if you actually care about both apples. If you don't, you don't.

I have a lot of respect for Simon and for his opinions so when Simon speaks I tend to listen. In thinking through his comment it really made a lot of sense. The problem that I have that caused such a strange reaction with the article that J. David Eisenberg posted was not that his points were not valid but that they completely ignored the fact that much of what he was refering to was no longer an issue when put into context with XSLT 2.0. But if your opinion is along the same line as Simon's then simply stating "while XSLT 2.0 is well on it way to a W3C recommendation XQuery brings several things to the development table that can make your development life a little less complicated, verbose, and extend from more of a procedural style syntax that a lot of us are more used to" will get absolutely nothing but applause from me.

To J. David Eisenberg's credit he has followed-up and it seems is taking the time to consider the comments made, working through them with a good attitude. Thats always a good thing to see so I think its best at this point that I simply let things be and hope that the attention thus far has been enough to help refocus the ideas presented into proper context. Armed with proper positioning and if you are one in whom is looking forward to working with XQuery as an XSLT 1.0 replacement, making no plans to use XSLT 2.0 it seems then you will be able to walk away with some good information to draw from.

Posted by m.david at 10:08 PM | Comments (2) | TrackBack

March 11, 2005

Dear J. David Eisenberg, Do you really think that at this stage of the game you can get away with an XQuery 1.0 to XSLT 1.0 Comparison and think no ones going to notice?

XML.com: Comparing XSLT and XQuery

ARE YOU KIDDING ME??? Come on now! I thought we were past the days that authors took a modern W3C spec in XQuery 1.0 and compared it to a 5 year old spec in XSLT 1.0 touting the "GREAT AND AMAZING BENEFITS" of using XQuery instead of XSLT, assuming that no one will notice the attempted con-job. I'll be honest, there are two things keeping me from spending the next hour taking your article and punching BIG FAT HOLES in it, tearing it into little tiny pieces, and exposing it to anyone paying attention for the fraudulent crap of an article that it is:

[UPDATE: * see bottom of extended post]

- I'm working against a *MUCH* more important deadline than is worth spending any more time beating down Yet Another Sad Attempt at Glorifying XQuery by Comparing it to XSLT 1.0
- We share a similar signature type with "First_Initial. Middle_Name Last_Name" and our middle names are the same.

Actually if not for the first the second wouldn't really buy you more than 12 hours or so to rewrite this using a modern spec to modern spec comparison... but maybe you dont care. Guess we'll find out.

So here's my offer to you:

Re-write this article using a comparison between XQuery 1.0 and XSLT 2.0 and either ask XML.com to repost the new article or write a comment that points to wherever you want to host it. Then shoot me a ping and if it seems like a much more realistic and fair comparison I will subsequently make an announcement as to its availability and cancel all plans to take things to the next level. What the next level? :D My full and unwavering attention to taking your post line by fraudulent line to a whole new level of understanding that I promise is not going to be a positive thing. For you. I may even invite a friend or two to join in on the festivities just to spice things up a bit.

I'll give you 1 week.

To anyone else who reads this post. Don't bother wasting your time with the above article. Its not only a fraudelent attempt to lure you into believing that XQuery is the defacto replacement to XSLT but it simply sucks! Worthless. A completely waste of your time. While its not even worth the effort to take a measurement I can guarantee you that I gained at least five times the amount of useful and accurate information earlier this evening skimming the pages of the National Enquirer at the check out line than I did reading this article. In fact it could easily be double that number.

Guess we'll see how the next 7 days pans out. Clocks tickin...

[UPDATE: You know what sucks about this? XQuery is actually a really cool language with tons of easy ways to query various data stores in a language more focused on the Query than the Transformation -- While you can do everything with XSLT 2.0 that you can with XQuery elegance does have to factor into things and in a lot of cases XQuery is simply the better choice for the job. But more damage is done by articles like this than good could ever become of it... I just don't get it.]

Posted by m.david at 05:39 AM | Comments (13) | TrackBack

March 10, 2005

Can you find a pattern in the following sequence: COM, .NET, ..ORG

In cruisin' by Lutz Reoder's web site (a .NET/COM Programming God to the unlearned) a few moments ago I noticed a strange anamoly that I'm sure is just that and nothing more... But in thinking through things just a little bit deeper I thought "Is that where ".NET" came from and if so is "..ORG" next? Take a look at his site again and notice the following stack:

Programming.NET
Programming.COM

I'm sure I've seen this a million times but it just now struck me that "In the beginning..." there was COM. Then came the .com world and suddenly we found the . at the end of acronym suddenly take on a whole new "." attitude, pop'n itself in front of the acronym with a sudden and immediatte "what are you going to do about it" sort of smirk, forcing us all to give heed to the "All Mighty ." in all of our newly found .live's on the .'net. You know who I mean: that Grand Master ".", the "." at the beginning of the domain tree that rules all .'s. The top of the .stack, the cream of the .crop, THE MASTER OF YOUR DAMN .DOMAIN!?)

Yeah, that ".". [For the record, .punctuation doesn't .count as a real "." in this little .hypothesis. Please .remove it from your .tally. thankyou.]

So to me .NET always seemed to symbolize Microsoft's deliberate recognition to the fact that the "All Mighty ." would now and forever rule the "All Mighty NET(profit)" and that would be it, the perfect marriage between the two great powers of our .modern .world.

But did the .NET .Forefathers have something even more .sinister in mind? Could it be that .NET was a .smoke .screen? A planned and deliberate layover en route to that all mighty day that the "All Mighty ." (ab)used it's "all mighty ." power, turned in NET(profit)'s general direction, thanked it for its (.web).services(.-*), and with a mighty .hop .hopped it's .a$$ on over the now .less NET and right on into the .ORG way of life, retaining its "." name of course to symbolize the fact that .open or .not it would always be it's "all mighty .self". [again, .punctuation; doesn't .count in the .tally. They might look very similar but "." sounds nothing like "." so no counting the "."'s, k? thanks :)]

Could it be that Microsoft has been playing us all like a .chess .piece from the very .damn .beginning???!!!

THOSE .BASTARDS!!!

I knew .Bill was a .Alien. [If you just reacted with a "bad grammar!" remark did you sound out the "." before Alien? Didn't think so their .grammar .geek.] :D

.Enjoy .Your .Day! :D

Posted by m.david at 01:00 PM | Comments (0) | TrackBack

March 09, 2005

via XSL-List | Follow-up response from Michael Champion from previous "Is there a reason for not using XSLT 2.0 as a default" post

NOTE: It seems that my statement that the split of the XSL working draft into the separate XSLT/FO working drafts back in the late 90's having something to do with Microsoft's current stance on support for the XSLT 2.0 working draft was completey off-base. In other words I muffed that one... 8| My apologies for a complete and total mis-cue on that one!

But no worries :) As it turns out Michael Champion recently posted a follow-up response that clarifys my previous muff and brings an official MS stance properly into place. To ensure that I have something to point to in any future comments on the matter I've copied his response below:

via XSL-List, follow-up comments from Michael Champion:
---
"M. David Peterson" wrote:
Date: Tue, 8 Mar 2005 17:32:48 -0700

"In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked. "

I was not at Microsoft nor involved with the XSLT WG in 1998-1999, but
my understanding is similar to those who replied that the XSL-FO /
XSLT split had nothing to do with MS shipping an XSLT implementation
that was incompatible with the eventual Recommendation. There were
some interesting points raised in the replies, and I really have no
opinion about their historical accuracy or fairness.

I can only speak to the *current* perception in the WebData XML team
at MS about the lessons we as a company and an industry learned from
this experience. The sense I get from my colleagues who were around is
that it *was* a good faith effort to implement what they understood to
be the draft spec, along with various improvements to make it suitable
to known customer needs. I will say that my personal view at the
time was that Microsoft's support for XSLT, flawed and premature
though it clearly was in hindsight, was an attempt to do the Right
Thing. Furthermore, it had the result of offering considerable
credibility to XSLT and creating a demand for XSLT tools and
experience.. I can very easily imagine a world in which XSLT shared
the fate of XLink, if MS had waited for the final spec and for
customer demand to emerge before supporting it in its core products.

The MS position going forward is, as I understand it from my rather
brief experience, NEVER AGAIN -- we will not ship support of a draft
Recommendation in actual products. That is why we removed the preview
implementation of XQuery from the .NET 2.0 framework, that is why we
are waiting until XSLT 2.0 is actually a Recommendation before
announcing any implementation plans or schedule. (XQuery in SQL
Server is a bit of a special case ... in any event we're not claiming
to ship a conformant implementation, just something that leverages the
years of experience that have gone into XQuery and meets pressing
customer needs).

Posted by m.david at 10:47 AM | Comments (0) | TrackBack

March 08, 2005

Way off topic: Hey, here's a picture to add to my Mt. St. Helens collection

via MSNBC.com:

It seems Mt. St. Helens has come back to life.

For those who take interest in this sort of thing last November I posted a link to a photo album of some pics I took from the air of Mt. St. Helens, Rainier, and Adams on a day Mt. St. Helens was showing a bit of attitude; an obvious precursor to the above photo from earlier today.

Enjoy!

Posted by m.david at 08:58 PM | Comments (0) | TrackBack

To XSLT 2.0 or To Not XSLT 2.0

An interesting thread has formed on XSL-List based on a post from Daniel O'Donnell in which he poses the following question:

... is there a reason for not using xslt 2.0 for most processing tasks?

The question is expanded and is then answered by several notable experts including Dr. Michael Kay, Elliotte Rusty Harold, and David Carlisle... The thread, thus far, is as follows:

Daniel O'Donnell to XSL-List on March 9th, 2005:

Hi,
I have a question that calls for informed opinion: is there a reason
for not using xslt 2.0 for most processing tasks? I'm thinking
especially privatish, and pre-processed things rather than on-the-fly
commercial applications.
The standard is now pretty stable, correct? and the processors seems to
be working well. Saxon 8b-3 is very good, and since Saxon 6.5.3 has a
bug that seems to stop it writing properly in Service pack two XP
machines, it may be a good time to switch anyway.
No doubt a trivial question, but I'd be interested in hearing what
people think. I'm engaged in a couple of new project involving xslt
where the question of 1.0 or 2.0 is real.
-dan
--
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge

---

Jay Bryant
---
I've been using XSLT 2.0 and the various versions of Saxon 8 since July of
2004. I've had very little trouble with either. Dr. Kay fixed the one bug
I found in Saxon 8 within a day (and I had already thought of a
work-around).

I can see two issues. First, you'll tie yourself to a single vendor.
That's not much of an issue, since you would probably pick a single vendor
anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
may change before it is finalized. However, that risk seems to be low, as
the working group is winding down (so I gather anyway).

I have been solving problems for my clients without undue difficulty (and
often much more easily than I could with XSLT 1) for 8 months now. Based
on my experience, I recommend that you go with Saxon 8 and XSLT 2.0.

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)

---

Elliotte Rusty Harold
---

JBryant@s-s-t.com wrote:

> I can see two issues. First, you'll tie yourself to a single vendor.
> That's not much of an issue, since you would probably pick a single vendor
> anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
> may change before it is finalized. However, that risk seems to be low, as
> the working group is winding down (so I gather anyway).

I certainly wouldn't count on that. It is far from unheard of for a
working group to think it's winding down when someone comes out of left
field and identifies an unrecognized problem that causes a major rethink
and redesign. It doesn't happen to every or even most specs, but it does
happen often enough to be a problem. So far I've seen this happen to
XPointer, XInclude, SOAP, and xml:id. (There might be others I'm just
not thinking of right now.)

There are numerous other specs where this should have happened but
nobody noticed the problems until after final publication. XSLT 2 isn't
done until the final spec is released, and maybe not then.

---

Dr.Michael Kay
---

This is essentially a risk assessment question: it depends on whether the
value you gain from using 2.0 is greater than the sum of the risks, where
risk is measured by the probability of failure multiplied by the cost of
failure.

You've had several responses with different views on the probability of
failure, but to make a decision you need to assess the other two variables,
and it's unlikely that anyone but you can do that.

I think we're starting to see one risk disappear, namely the risk of being
locked into a single supplier. There are now three XSLT 2.0 processors
released, and I'm sure we'll see others in the next few months. (I have no
idea, of course, what quality they will be.)

I think the risk of seriously disruptive changes to the spec is now
reasonably low. There will be minor changes, but I'm pretty confident they
will be easy enough to absorb for a typical project. The working groups are
now spending nearly all of their time discussing edge cases - examples from
the last meeting include how to handle leap seconds, whether or not it's
legal to write "10 div 3" without the first space, whether or not the
numeric literal 1.0e10000 is an error, whether tokenize() applied to an
empty string returns an empty string or an empty sequence, whether
resolve-uri() should reference RFC 2396 or RFC 3896, how lax validation
handles an xsi:type attribute, whether (1 div 0) is a static error or a
dynamic error. Frankly, none of these are things that will affect the
outcome of more than 1% of stylesheets. But of course, committees are not
always predictable: there can be a tendency for new people at a higher level
of management to get involved at the last minute and this can sometimes rock
the boat.

There is of course a contingency plan for a project if the spec does change:
you can carry on using the software that exists today.

I'm personally seeing a lot of projects where the gain from using XSLT 2.0
far exceeds the potential pain. But I wouldn't advise every project to use
it: on a billion-dollar project, it's always worth erring on the side of
caution.

Michael Kay
http://www.saxonica.com/

---

David Carlisle
---

> The standard is now pretty stable, correct?

That can't be guaranteed, XSLT 1.1 was just abandoned for example.
I imagine that after this length of time the WG aren't keen to do any
major redesign, but to assume stability at this stage is to assume that
the public common process won't be taken seriously.

That said, I'm using xslt2 more and more, but I'd written quite a lot of
XSLT1 before that was finalised as well.

David

---

M. David Peterson
---

> (There might be others I'm just
not thinking of right now.)

In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked. I would tend to think that the W3C
has made the necessary changes to ensure that this kind of thing
doesn't take place again but I would also consider the fact that, as
Mr. Harold recognizes, last second changes happen often enough that
the possibility must be considered when making any long term plans for
a technology.

With that said, it seems the latest release of the XPath 2.0, XSLT
2.0, and XQuery drafts have gone a long way into fixing a lot of the
areas that may have been considered questionable or potential problem
areas but caution still must be employed none-the-less.

Best regards,

]]>

David Carlisle
---

> In fact one of the primary reasons Microsoft has held back from
> providing direct support for the XSLT 2.0 spec is based on the last
> second 'split' of the 1.0 spec into the XSL (FO) and XSLT
> specifications causing an incompatible processor to be propagated and
> a support nightmare to be invoked.

I think that's a very skewed view of history:-)

The split between FO and XSLT into two specs wasn't that late in the
process : including the REC there were 7 drafts of XSL(T) only the first
two of which were combined with FO.

and was essentially irrelevant to the microsoft implementation
as it never implemented the FO part of the draft even when they were
combined, splitting it just made it easier for the transformation-only
implementations to claim conformance to a named spec rather than just to
chapter 2 of a combined spec.

msxml2 implemented a language that had a passing resemblance to the
transformation language in the XSL draft of December '98. Even if it had
been a faithful implementation of that draft, releasing an implementation
of a draft spec in a full non-beta release of a piece of software
distributed to 90% of the world's desktops was a mistake, although at
the time I think many of us thought it was probably a good thing,
spreading the word... It's easier to take a different view with hindsight.

> I would tend to think that the W3C has made the necessary changes to
> ensure that this kind of thing doesn't take place again

I don't think the W3C process can have any effect on such
things. Companies (or people) will take commercial decisions on whether
to release (or use) software based on a draft spec. If they do release
such software again they will take commercial decisions about whether
to change the software as later drafts come out.

David

---

M. David Peterson
---

Thanks for this added info... Of course its easy to develop an opinion
in one direction or another based on the information you are aware of
so it certainly helps to understand things further from someone who
has watched this process from the beginning.

Cheers :)
]]>
---

If you have any additional comments or questions please, if you do not belong already, join XSL-List, and then add your comments or questions to the thread entitled

[xsl] Is there a reason for not using XSLT 2.0 as a default

Posted by m.david at 07:41 PM | Comments (0) | TrackBack

March 07, 2005

Socorro County Community Calendar - They're smarter than I first realized!

They're back!

And it seems they're smarter than I first realized:

Introduction to XML, 5:30 p.m. — Speare 116. "XSLT II: XPath and basic XSLT." Free class.

Let's see, I see a Python class again... smart. And it seems this is the second of at least a two part series on XPath and XSLT. Very Smart! But wait.. all this intelligence and yet still no sign of XQuery? They are REALLY smarter than I realized ;) Oh thats right XQuery... I hope you have enjoyed your vacation away from my daily beatings cuz' I'm back! :D See this post for a better understanding as to why the layover... :D

Posted by m.david at 09:52 PM | Comments (0) | TrackBack