February 26, 2006

Ben Hammersley : "Ship or comment - pick one."

Through a lens sharply

I’m beginning to remember the primacy of just creating stuff. It’s all got a bit too meta around here lately. Ship or comment - pick one.

I love Ben's point regarding being too "Meta". Good advice, and something I personally need to both listen to and act upon.

Directly extending this comment, "Ship or comment - pick one." adds a nice sense of immediatte action; something I plan to directly react to in the "good reaction" sense.

Speaking of which,

If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.

Two different people. Two different subjects. The same point.

Whether coming from Don, or from Ben, "pick one" and get on with it.

That's my plan anyway, although I don't see the need to pick one over the other... They're both industry icons in whom both know a great deal in regards to the subject matter they specialize in. With this in mind, and both with a history of "shipping" stuff, its interesting to note that they both seem to recognize that theres two types of meta in the software industry:

* chatter
* data

Sam Ruby - Intertwingly:

It’s just data.

I wonder which 'meta' Sam (another proven "shipper") thinks matters most?

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

February 25, 2006

This Is A Call Out To All RSS Developers

Now that I have absolutely nobody's attention:

RE: [rss-public] Microsoft Feeds API Enclosure Test

For what it's worth, there will be updates to this API over time, so it is possible that we will have an API that makes the content available in Atom format, as well (or in the native format, though that's harder because it requires that we persist the original XML). This feedback is all extremely useful in helping us figure out what the right thing to do is.

Three things:

* The developers who are into using data feeds, or developing tools that generate data feeds, have all switched to Atom, even if that means from an internal "I prefer Atom, but I have to support RSS '2.0'" standpoint.
* You will get a TON of constructive feedback from the Atom development community.
* You will get a TON of destructive criticism from the RSS '2.0' 'community'.

[NOTE: Notice the difference between 'Atom development community' and 'RSS '2.0' 'community''. As already mentioned there is no *REAL* RSS '2.0' development community (thats not to suggest that *REAL* developers are not developing for RSS '2.0', and instead that the development discussions in the data feed community have shifted, primarily, to Atom, where as in the RSS '2.0' community all you will find (for the most part) is drama.]

Regarding:

This feedback is all extremely useful in helping us figure out what the right thing to do is.

I doubt it will take much more than a few weeks for you to realize that the Atom development community is all about serving the needs of the current and future data feed developer, no matter the format. If you want constructive feedback based on real world testing, you'll find exactly that in the Atom community.

That said, I personally feel that by converting over to an Atom-based format you will find that a lot of folks will be going out of their way to help make IE7 the best data feed browser available. Of course, without an official RSS '2.0' namespace, that would require the need to create one. But it seems that primary concern is not exact conformance, and instead general conformance. So creating a namespace that fills the namespace need shouldn't be all that hard of a pill to swallow, even if some of the RSS '2.0' 'Community' folks (or should I say folk?) feel otherwise. [UPDATE: Actually, come to think of it, there are several examples from reputable folks that showcase that you can easily map an RSS '2.0' feed to Atom without any loss in data quality. So in reality, I don't think you would need to worry about an RSS '2.0' namespace afterall. Even better!]

The result?

A better IE7 browsing experience = "the right thing to do."

To summarize:

Why even go down the

For what it's worth, there will be updates to this API over time, so it is possible that we will have an API that makes the content available in Atom format,

road?

Do it right the first time and you won't have to. While you most definitely *WOULD* need to update the API to provide native support for the Atom format, the same is not true about RSS '2.0'. Very few folks who's name is not Dave will be beating down your door to provide native RSS '2.0' support. To the contrary, in less than a years time a *TON* of folks *WILL BE* beating down your door for native Atom support.

Just do it now and save yourself the headache.

Need help?

Just ask the Atom development community, they'll be happy to help, I can promise you that. :)

Something to think about anyway :)

[UPDATE: Something else to think about... Ping the MSXML2 team and ask them how much of a pain in the a$$ it is to support a version of XSLT that pre-dates the final release of the spec. Okay, so the situation is not a 1-to-1 mapping, the ultimate end result more than likely is. Make the switch to the data feed format prefered by a significant majority of the development community and avoid the headache (and 'wallet-ache'!) of providing support for a long since dead-and-buried 'specification' in RSS '2.0' (.0.2? something like that anyway.) for the next 10 years.]

Posted by m.david at 03:57 AM | Comments (2) | TrackBack

February 24, 2006

Saxon/Saxon.NET Version 8.7 Now Available (Both B and SA)

So its now official, and I can finally let the cat out of the bag!

As per Dr. Kays announcement earlier today, The Saxon.NET project has been officially absorbed into the offerings of Saxonica LTD, With direct support offered from none other than Dr. Kay himself. The official announcement is copied below.

When I started the Saxon.NET project with Pieter almost two years ago, I did so with one goal in mind: To transfer this project to Dr. Kay as soon as he felt the time was right. It was obvious to me then that the best way to do this was to keep the code base as close to the original as was possible such that the transition would be an easy one. While early on in the project there were various attempts at a conversion to a complete C# source base, with each release of IKVM.NET it became more and more obvious that attempting to both port the source to C# while attempting to keep up with each release of Saxon was completely unnecessary. Jeroen Frijters, Mark Wiellard, and the rest of the folks who have helped bring together IKVM.NET and the Classpath project deserve the credit for making all of this possible.

Thanks guys! Because of you, I can finally state:

Mission Complete :)

What's next?

Sleep. ;)

After that?

Following the suggestion of Dr. Kay, I plan to unveil the next stage of this project, that of a community-based "workshop"-styled research project in which anyone and everyone who so desires can get involved with playing around with new ideas, contributing code, ideas, or whatever else , of which, based on Dr. Kay's discretion at some point has the potential to find its way into the official Saxon code base.

Sound like fun? (If yes,) Excellent! More details to follow.

One other important piece of this: A lot of folks played a hand in making Saxon.NET a success story; a lot of those folks work for, or are in various ways (like the XML-MVP's) connected to Microsoft. Believe it or not, this project *COULD NOT* have been successful if it wasn't for the efforts of Microsoft. Of course, its not limited to just MS folks, but the list of MS folks who have contributed to this project in various forms will probably amaze a lot of you. This list will be included online and made available with the launch of the community workshop/research project mentioned above.

Its also nice to see that the general idea of creating a JAXP-influenced interface (One XML Source-type in, One XML Source-type out) has found its way into the final architecture that Dr. Kay designed from scratch. This always seemed like the right area to focus on, so I'm glad to see that he felt the same way. As he mentions in the announcment below, the final architecture is something thats a God-send to us .NET developers, and is something that even the JAXP-folks will without a doubt seek after in envy.

Great stuff! :D

Thanks to everyone who played a part in this project! As you can imagine, I'm pretty excited at the moment to both see this project make its way into the hands of its rightful owner, as well as the opportunities that are ahead. The fact that Dr. Kay has given me this extended opportunity to further extend the reach of the XSLT language and the Saxon product line, through a community-based interface is something I *TRULY* appreciate. This should be a lot of fun for everyone who chooses to get involved.

Thanks Dr. Kay!

The official announcement is below:

Saxon 8.7 is now available. Both Saxon-B and Saxon-SA (the schema-aware
product) are being made available simultaneously on the Java and .NET
platforms.

Delivering Saxon on .NET is an important development; many users have held
back from migrating to XSLT 2.0 because of the limited availability of
products or because they had constraints tying them to the .NET platform.
The new release goes considerably further than previous Saxon.NET releases:
it integrates much more closely with other .NET services such as the
System.Xml parser, and it provides a new API designed to fit in with the
stylistic conventions of the .NET framework. Also, because this release is
delivered by Saxonica, it has been through all the same tests as the Java
product, and the documentation is fully integrated.

I have to express my appreciation to Pieter Siegers Kort, M. David Peterson
and others who pioneered the approach that has been used to create this
product; and also to Jeroen Frijters who produced the IKVMC cross-compiler
on which the technology depends. The Saxon code is still written in 100%
Java, except for the new API front-end which is in C#. The Java code is
compiled as normal, and the byte-code is then translated into native MSIL
for the .NET platform using the IKVMC compiler. Run-time library services
are obtained partly from the GNU ClassPath library, and partly from the .NET
framework classes.

I'm quite pleased with the new API, which is documented at
http://www.saxonica.com/documentation/dotnetdoc/index.html (start with the
Processor class). I think it's a lot cleaner than either the JAXP or the
System.Xml.Xsl APIs, and adopts a uniform approach to compiling and running
XSLT, XQuery, XPath, and XML Schema. I may well port it back to the Java
product in due course.

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

Posted by m.david at 06:42 PM | Comments (2) | TrackBack

Multiple Enclosures = Download All Of Them?

[UPDATE: Mike Champion has taken a few moments to share a few of his thoughts regarding the latest episode in the RSS soap opera. If you're a fan of the Atom format I think his comments will bring a smile to your face. Thanks for taking the time to comment Mike! Your time is without a doubt, appreciated. :)]

Workbench: Really Simple Syndication: The Joy of Specs

The preview edition of Microsoft Internet Explorer 7 only downloads the first enclosure in each item. Power Line users who listen to its podcasts with that browser must manually download the other enclosures, which removes the biggest advantage of podcasting -- instant availability of the files.

Firstly, RSS sucks. Don't use it. Use Atom instead. Why? Cuz' this kind of intra-rival "He said, she said, his intent, her intent" crap doesn't exist. The spec was developed by folks who have a history of writing open standard specifications. The RSS "spec" was created by someone who has a history of creating chaos.

Which group do you think is more capable of producing something that has been well thought through, leaving very little to the imagination?

(NOTE: If you answered RSS, BZZZZZZZZzzzT.TryAgain();)

Moving forward:

Having some experience with producing podcasts, I can promise you that never in my mind did I think "Lets produce several different versions of the same thing so that everyone can download *ALL* of them, to then choose between MP3 format or WMA." To me, anyway, that just seems like a silly thing to assume as the default. Why require an increase in bandwidth cost, just so the consumer can pick and choose between formats at their convenience and my cost?

Of the podcatchers I have used, they seem to choose either the first on the list (IE7) or a format in which it can play (iTunes). From what I can tell, given that iTunes doesn't natively understand WMA, it downloads the MP3 format. Given that it doesn't understand how to play WMA, why would it choose to download both formats? Its simple enough to build basic intelligence into a consuming application to look for a MIME-type and extension it understands. To not build that intelligence, and instead just burn bandwidth for the sake of burning bandwidth?

Dumb.

With this in mind, wouldn't it logically follow that a data feed that contains enclosures should be generated around the general idea that for each entry, if multiple enclosures exist then they should contain the same content, but a variety of formats such that you can reach the broadest audience? This allows nicely for the notion that each entry can contain a summary as to what is contained in the podcast, and have this summary apply to each enclosure. Given you can only have one summary per entry, the notion that multiple enclosures within the same entry can represent completely different content all together is just ludicrous.

In blogging terms, one entry doesn't represent multiple posts, so why would podcasting be any different? Adding to this, a lot of logic can be implied using separate entries for each podcast segment. For example each entry could represent a start and stop point for various segments of a podcast such that a player could logically provide a summary for each segment, a combination of categories, a link to comment on each segment, etc... With all of this in mind, I can't think of any logical reason why you want to provide multiple enclosures in the same entry that contain different content.

Don't get me wrong, I'm not suggesting that this "idea" is a wide-spread notion that a lot of folks feel is okay. What I am suggesting is that the idea that downloading more than one enclosure that contains the same content, just a different format, is ridiculous, and combined with this last piece theres no logical reasons left as to why one would put multiple enclosures that contain different content into the same entry.

If any of you can think of why any of the above is incorrect in any way, can you clue me in? If it is, then I guess I just don't get it.

Posted by m.david at 04:49 PM | Comments (2) | TrackBack

February 23, 2006

Help save a life today!

Dear [WW:*]:

For the next 3 weeks, we have an opportunity to really help fight global AIDS and extreme poverty.

Right now, Congressional leaders are deciding how much life-saving assistance the U.S. will give to the world's poorest countries-and they need to hear from YOU!

Let's keep up the positive pressure: Please sign a Letter to Congressional Leaders Today and Help Save Lives.

Key leaders in Congress are making choices now about how America will fight global AIDS and extreme poverty. Every signature counts—it means our leaders know that we believe doing even more is in America’s interests and it’s the right thing to do.

Sign a Letter to Congressional Leaders Today and Help Save Lives

Because of your efforts, America made promises in 2005 to fight AIDS and extreme poverty. Today, hundreds of thousands of people around the world are alive because of America's historic commitment to fight AIDS. Thank you!

By working together as ONE, we can do even more.

Thank you,

The ONE Team

Posted by m.david at 11:37 PM | Comments (0) | TrackBack

What REST Gets Right (but doesn't realize it), What SOAP Get's Wrong (and doesn't realize it) And How Monad (Microsoft SHell (MSH)) Fills The Gap (and doesn't realize it) [Part 3 of 3 in a Mini-Series]

A good majority of software developement at the present time revolves around the Namespace (or Classpath), Class Name, Method/Function[Object to process]/Attribute signature.

The Monad Project (Microsoft SHell, or MSH) implements a similar signature, but uses the term "Verb-Noun" to describe the various commands available.

This type of signature makes sense. Using some hacked notation that resembles a little of everything we should all understand (Domain (('Namespace ~||~ 'Classpath), :ClassName), Method(:Object, Attribute*)).

The RESTafarians stand behind the 'cruft' free approach to URI/IRI conventions, and yet there is no established signature specification as to what that means exactly.

The general approach makes sense:

Make the URI/IRI easy to remember/understand and you make it easier for your site visitors to access the various areas of your site, or the various capabilities of your weblication.

The SOAP folks understand the need for an address to invoke a transaction, but fail to recognize that quite a bit of implied information as to the desired transaction can be embedded into the URI/IRI itself, dumping a bunch of baggage in the process.

Since we can quite easily write a URI/IRI that looks like:

[protocol]://domain.foo/send/message/m.david

That maps quite nicely to the signature of:

(Domain (('Namespace ~||~ 'Classpath), :ClassName), Method(:Object, Attribute*))

and in doing so imply with this URI/IRI that we would like to send a message to m.david@domain.foo, then why don't we?

More of us instinctively understand the signature, it would make sense to even the non-geeks, and with a reduced number of verbs as compared to the unlimited potential of nouns these can be applied to we can easily create a standardized group of actions that we can all build against.

With this in mind, why are we wasting our time not using the URI/IRI to our advantage?

Thanks for taking the time to read. This stuff is important. Can we stop the religious war and just get our work done now?

Thanks :D

[END OF MINI-SERIES RANT]

Posted by m.david at 06:33 PM | Comments (0) | TrackBack

On Good/Bad OSS, OSS 'Business Models', and Its Relationship to the REST/SOAP Religous Debate [Part 2 of a Mini-Series]

Of all the successful open-source projects that come to mind that I personally use with any consistency, not a single one of them actively pursues "donations" (Apache, Mono, Mozilla, Saxon/Saxon.NET, IKVM, more recently 4Suite/Amara (still gearing up, but I see it as a farely significant piece of my future, CherryPy (ditto), ICECAST, and a few other smaller projects) and instead have properly built a business model around licensing extended feature-sets, support, consulting, and other reputable forms of OSS financing such as corporate sponsorship.

The above projects are examples of OSS done right. There's a need. The community rallies around that need. That need is now taken care of by folks who know what they're doing.

What then represents the wrong way?

I'll stop short of insults (rarely do insults bring about anything but insults in return. Not a lot gets accomplished when you make insults the core message of a particular post) and instead provide a general rule of thumb:

'Guilt Marketing' is bullshit.

OSS projects that aggressively seek after donations, using terms such as "Have you donated yet?" in pop-up boxes that require you click a yes/no-type button contained in an alert box of some sort, or even those who believe that a good and reputable business can be built around a donation-based system are flat-out wrong. It doesn't work.

Accepting donations is one thing. If you are not aggressive about it, then fine, whatever... Not a big deal. If its a side gig that fills a needed niche, and people want to throw you a few bucks, and you make it easy for them to do that? You're not going to here me complain.

But using guilt marketing?

Like I said, bullshit.

OSS can be both a good thing and a bad thing. When you introduce half-a$$ed software solutions that do little more than confuse the market with mixed messages, diluting the perceived value of the good and reputable products in this space, more damage is done to the economy than can be fixed by the money "saved" by the folks using these solutions. When you attempt to disguise a product as "free" but insist on using guilt marketing tactics to make people feel like they are not doing their part unless they donate to the cause...

= The "Send me your weak, and your old, and I will give them REST!" Gospel Hour

The same can be said about folks who undermine the good reasons for using SOAP-based solutions by hiding behind the notion "if its difficult, its evil!"

No. Its just difficult for the average Mort. Thats not a bad thing. There are programmers, good programmers, great programmers, and mortal God's. When you are performing a banking transaction, do you want the software developed to perform this transaction written by a good programmer, a great programmer, or a mortal God?

If it take's a mortal God, or at very least a great programmer to ensure that my transaction completes successfully, and does so secured from end-to-end, and these same great programmers/mortal God's suggest they need something a little heavier than REST to get their job done...

Then shutup and let them get their job done.

Unless, of course, you don't mind if your bank only gets through the deduction portion of a transaction that contains a deposit as well. Or maybe you want someone to charge your credit card, but never ship the package, or ... (fill in the blank with anything that requires and all or nothing type atomic fulfillment)

Yeah, SOAP is *THAT* important. From the standpoint of posting content to a forum, or updating an Atom feed, its not. But to mission critical "It's all or nothing" transactions, it is! No religous movement is going to change that. Instead, it clouds the issues at hand and confuses the economy.

This needs to STOP! If you don't need SOAP, then don't use SOAP. If you do, do. But by making a religous war of things, you're doing a TON of damage, much of which is irreversible.

Seriously, you need to stop. No, I'm not kidding.

Stop.

Posted by m.david at 06:03 PM | Comments (0) | TrackBack

REST? SOAP? I Could Care Less... It's All About Sending And Receiving Messages : [Part 1 of a Mini-Series]

So here's the dealio, yo: I 100% agree with both Mike and Don and anyone else who agrees with their point.

The most important piece to all of this chat-chat-chattering going on in the blogosphere seems to be overlooked. No matter which way you slice it, it's all about the messaging.

REST+POX? SOAP? These "questions" shouldn't be seen as a dividing line "one over the other" and instead "Is REST+POX enough or do I need SOAP to accomplish the task at hand?"

If I want to toy around with some pic's on Flickr, the chances of me needing the complexities of SOAP are pretty slim. If I want to ensure that a financial transaction has met the "Atomic" requirement of completing the entire transaction successfully or backing out of the entire transaction, then SOAP *IS* required!

Actually, thats not true.

I guess you could go invent your own XML messaging framework for complex transactions, but my guess is that in the end it would look a lot like SOAP, so why not just use SOAP and be done with it?

"Because that would mean *THEY* won and *WE* lost?"

Huh? Man, come on, go buy a damn clue.

This *ISN'T* a religous battle. This *ISN'T* about "one or the other, but not both!"

*IT IS* about which one do you need to get the job done. End of Story. (but not of post... yeah, yeah, cry me a river... you'll get over it. ;)

For those of you who are still a bit confused, here's some general guidance:

Sometimes the message being sent it lightweight and *DOESN'T* require a lot of overhead. In such cases a REST+POX solution makes sense. The reason REST+POX gets so much hype is because its:

* Simple, so any member of the "View Source" generation can figure out how it works and how to use it.
* Efficient - Low overhead because it uses an extremely cheap carrier pigeon in HTTP

Sometime the message being sent is heavy and *DOES* require a lot of overhead. Sometimes a complex set of structured information is required, and sometimes you can't just "Let go, and Let God". You need a response, and your not going to hang up the phone until you get one. Carrier-Pigeons might be able to deliver the message, but counting on them to wait for a return response, to then bring that response back to you isn't always the best strategy. In such cases a SOAP-based solution makes sense. The reason SOAP gets so much flack is because its:

* (see points regarding overhead and complexity)

Whether we "I don't see type's, I see (please fill in you prefered variation of the Matrix cliche' quote here)" folk's want to admit it or not, there *IS* a need for this type (oh, can I say that word and not be beaten down by the Society of the Politically Correct Hackers of the Type-Less Mind"? If not... I'm ready. Bring It.) of "Heavy Messaging" *IS NECESSARY*.

Whether the HTTP aficionados want to admit it or not, HTTP *DOESN'T* solve 100% of the problems. In a lot of cases, like GETting information from a web server, or POSTing information to a web server (a message to a forum, etc...) HTTP gets the job done, and we're happy. A lot of traffic on the web can be served quite happily with HTTP as it doesn't need anything beyond this to accomplish the task at hand.

Great! Fantastic! Wonderful! Well, until you need something a bit more industrial strength that goes beyond what the stateless verbs GET, POST, DELETE, PUT (Can I say that word and not be beaten the SPCHTLM? If not, please see previous prompting :), etc... that HTTP brings to the table. When this happens to be the case, then no matter how how hard you try, HTTP *ISN'T* going to get the job done.

So here's the extended dealio, yo:

* The majority of the web population is served with a REST+POX solution.
* More People = More Voices = Loud (sometimes annoying) Chatter
* = "Hmmm... How can we profit off of this?"
* = "I know! Lets start a religous movement so we can RAKE In All The 'Sucker Dough' While We Plead Our 'Evil! Evil! Evil!' case."
* = The "Send me your weak, and your old, and I will give them REST!" Gospel Hour
* = RAKE in even more "Sucker Dough" while we plead Our "Evil! Evil! Evil!" case!
* = The "Send me your weak, and your old, and I will give them REST!" Cable Channel

[UPDATE: those last two were in the wrong order because and unfortunate copy/paste "incident". Don't worry, no line-items were harmed during the recording of this post. Just re-ordered a bit, and added to.]

Does the term "Please Donate" sound all to common and familiar to any of you? [UPDATE: See Part 2 of this mini-series for a further understanding of what I mean.]

Think about it.

Your being taken for a ride folks. If REST+POX is all you need, then don't worry about using SOAP. If its not. Then do. End of Story. (and of post. But not Mini-Series. Oh yes, theres more to come. You can believe 'dat!)

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

February 22, 2006

NOTE-TO-SELF:

Don't Gush.

Saxon diaries :: Thanks for the compliment

It's nice when people say nice things about you, though slightly embarrassing when they gush.

Don't you just love life's little lessons (especially when they're conveniently packaged in a byte-sized data feed format for ease-of-consumption-based learning :D)

Posted by m.david at 11:30 AM | Comments (0) | TrackBack

February 21, 2006

On The Tragedies and Triumphs Of G. Ken Holman

Anyway ? Blog Archive ? Courage and Cancer

For those who don’t know, Ken has been a stalwart in the SGML/XML community for many years, taking part in various standards committees as well as being a well-regarded teacher and speaker. He’s had a bad run health-wise recently, culminating in a bout with prostate cancer (which now appears to be effectively cured, though some side-effects still remain). The details are at Awareness of Male Cancers – my personal stories; what may be startling is that even test results within the normal range can indicate cancer that needs to be treated. Here’s hoping that few people need to go through what Ken just has, but if you do, I hope you recover well and quickly.

Whether you realize it or not, if G. Ken Holman had not been a pioneering member of the SGML/XML community, continuing forward to develop, evangelize, and teach about these and related technologies, we would not be anywhere near where we are today in terms of the development and advancement of these technologies, as well as understanding how these technologies work, and how we can integrate them into each of our development lives.

For those unaware Ken has been diagnosed and won the battle with cancer, twice. Firstly, with Breast Cancer, and secondly, with Prostate Cancer. Both of these previous links gain you access to his personal thoughts, feelings, and overall experiences of both tragedies and both triumphs.

Ken, our lives would be lacking a much desired richness if it had not been for you, your work, your dedication, and your overall presence within our community. I am both happy and thankful to learn that the blessing of your presence within our personal lives and our community will be continuing forward for what I hope is many, *MANY* years to come. You mean a lot of wonderful things to a lot of wonderful people. Thank you.

Posted by m.david at 09:48 AM | Comments (0) | TrackBack

Bush: U.S. on Verge of Energy Breakthrough

Bush: U.S. on Verge of Energy Breakthrough - Yahoo! News

MILWAUKEE - Saying the nation is on the verge of technological breakthroughs that would "startle" most Americans, President Bush on Monday outlined his energy proposals to help wean the country off foreign oil.

So "Startle" Us!
---

As many of you know, I live in the United States. As is probably fairly obvious, generally speaking, I choose not to bash the US Government at any and every given opportunity. I say 'generally' as there are those times (like a couple of days ago) when I am just fed up by the idiots who have somehow stumbled their way into power, yet continue forward in their idiotic ways without so much as an effort to try to get a clue.

Even still,

The type of bashing I involve myself in is not of the type that I feel can be seen as anti-establishment and instead anti-idiocracy. Bashing the US Government at any and every given moment does nothing to help fix the underlying problems, and does everything to undermine the establishment by folks who are ill-prepared to stand up for what it is that they think they believe. Why are they ill-prepared? Because 99.100% of the time the anti-establishment smut is founded on opinion without even so much as a single link to any other source other than the opinion(s) of someone else. [1] How can I stand up for something, and do so with confidence, that has been built by something that in and of itself contains no representation of meaningful fact, and instead meaningless opinion?

I can't. I might think I can. But I would be wrong.

With all of this said, I must admit that I have been recently getting to the point where I was about to throw in the towel with the Bush administration. Thats not a statement that should be seen as a suggestion that before now, I was for the Bush administration, but now I am considering going against them. I am not for or against any administration. I am for the people. Whoever can best represent the people and our current state of affairs is the person in whom I am going to vote for. For example, in 2000 and 2004 I voted for Bush. Not because I believed he contained all of the best qualities, or that there was nobody better on the face of this planet who was more qualified for the position, and instead because, at that point in time I felt he was the best choice of the two choices that had even the slightest chance of winning the election.

To help showcase the fact that I am someone who doesn't walk party lines, In 2008, I am presently of the belief that if Al Gore decides to run for re-election ;) he will be the best choice that we as citizens of the United States, in whom have the ability to vote, can make. In fact, I have a project in-the-works (it'll be ready when its ready, and not any sooner) to help encourage Al Gore to run for re-election, and if successful, to encourage citizens of the United States with voting credentials to vote for him, providing solid, factual-based reasons to do so.

Why do I feel Al Gore would be the best choice we could be given for the 2008 Presidential Election? Because I feel that the current affairs of the United States Government must be placed smack dab in the middle of saving our planet if we are to have any hope of living on a planet that even closely resembles that of a planet with life-sustaining qualities. I also feel that the situation we will be faced with in the 2008 time frame in regards to foreign-affairs will require someone who has a proven and solid experience with forein affairs from the perspective of a United States Government standpoint. Al Gore has that experience. Therefore it is my belief that, again, if he chooses to run, he will be the best choice for President in 2008.

The fact that their seems to be a tad sense of glimmering hope that come January 2009, he would be taking over the controls of a "White House Administration" who has already been working towards similar goals can only result in good things.

This is a *FANTASTIC* thing!

Enjoy Your New Found Hope That Our Planet Might Still Be Around In Fifty Years For Our Children And Grand Children To Enjoy-enhanced Day!

---
[1] : In some cases the opinions of folks must be seen in the light of expertise and/or authority (in the case of 'or authority' this would represent those who speak for-and-in-behalf of someone else. In this case they have the authority to represent the opinions of the experts they represent). When this takes place, then an exception to the rule must be invoked.

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

February 20, 2006

On XSLT 2.0/XPath 2.0 Type non-Equality and Comparibility Algorithms

Saxon diaries :: Comparability

Dr. Kays original "Comparability" post from last weeks provides some interesting insight into the inner-dynamics of a standards body working group -- something that I believe is a true characteristic of *ALL* working groups, not matter who the parent org happens to be. As soon as you have a chance, its definitely a *MUST READ* post...

Then again, they all are, aren't they.

Ummm... yep! I guess that means we can move on then. :D

So I just happened to be in the general WW:Neighborhood and decided to stop by Saxon Diaries to see what new and exciting things might have taken place since my last visit (no, I have no intention of telling you exactly when that was... Just know it was earlier... (today.)

While there were no new posts, there was an interesting comment left by Dimitre that brought up some really quite interesting points...

I don't want to plagiarize the whole thing, so a quick click of the above link will allow you full access to its content (that reminds me... Dimitre, when are you going to start blogging so I can add you to my stalk-- err, um, so I can... uhhhh... hmmm... OH! 'Chalk' you in for a visit every now and again (that was a close one, huh?!!!)

Yeah, K... cuz' uh, yeah... you need to start. :D ;)
---

So back to Dimitres comment... at the bottom of his post you will find the following paragraph:

FXSL has a set of type-processing functions that can determine dynamically the type of an item and return it as a string or return the constructor function for this type. This could be used to determine type (in)compatibility in case the backdoors Mike points out did not exist.

Uh, you do? Hmmm... Thats sounds like it could be quite handy! :D

I'm off for study time folks! This sounds like it could be WAY TO VALUABLE of a tool not to begin an immediatte inclusion into my ever growing set of things I am thankful for. For example:

"Dear God, Thank you for Dimitre's FXSL project... Oh, and for his brain too! On, and for that matter, Dimitre too! I would be a bit lost in my development life without these in my toolbag, so gracias Amigo!

"One last thing... Could you help convince him to start a blog as well?

I'd appreciate that there Big Fella... (innerthought: I wonder if calling God "Big Fella is really the smartest thing to do... (innerthought to innerthought: Uhh... He can here you say that.. and this for that matter! (response to innerthought of innerthought: Isn't that invasion of privacy? I mean, if a man can't even expect to find privacy in his own [virtual slap fest from innerthought of innerthought commences]"

[response to innerthought of innerthought: hmmm... that kind of hurt. I'm blogging this!]

[SUDDEN REALIZATION:
Oh shoot!
]

"Dear God, Amen!

"Sorry 'bout that... got cut off by some random punk thought in my hea[Cut-off Answer from God: No, that was me.]"

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

February 19, 2006

People Baffle Me

Okay, so this is so off topic don't bother reading it if you have limited time.

In fact, this will more than likely be the first and last time you see anything that's even closely related to celebrity gossip, although this isn't anything about gossip, and everything about WTF?!

That said:

Spears Fears Princess Di Fate - Yahoo! News

Initially , Spears said she acted "instinctively" to protect her son. As the furor failed to die down, she copped to Access Hollywood that she "made a mistake."

That wasn't enough for parents groups or even U.S Secretary of Transportation Norman Mineta.

"No matter who you are, there's absolutely no excuse for this display--not instinct, not fear, not even reckless paparazzi," Mineta said in a speech earlier this week. "It's irresponsible to compromise the safety of a child for the sake of the moment."

Ummm... Okay, so I'm being chased down by someone who is demanding that its their right to be my virtual shadow, snapping pics of me at every opportunity that is going to sport them a 250K paycheck, and me some BS headline stating "Proof he's cheating!", the proof showcased by the "fact" that as I am running into the store to get my groceries and get back out such that I can get home and away from this phreak I , quite literally, bump into some woman accidentally, to then try to grab her to keep her from falling, and as a result find a pic of me "embraced with another woman!"

Was I?

Yes!

Was I cheating?

Ummm... well... setting aside the fact that I would first need to start dating someone to then be accused of cheating on them...

Obviously not!

"But pictures never lie!"

Uh, whoever told you that lie was obviously trying to hide the fact that the pictures (whatever they may have been... this is a non-specific point) were faked. Add to this the fact that the day Photoshop hit the market, our "life in pictures" would never again be represented in quite the same way as it once was... that's not always a bad thing, but its not always a good thing either.

K, so far off topic its killing even me.

"No matter who you are, there's absolutely no excuse for this display--not instinct, not fear, not even reckless paparazzi," Mineta said in a speech earlier this week. "It's irresponsible to compromise the safety of a child for the sake of the moment."

Wait, hold up...

not instinct, not fear, not even reckless paparazzi,

Um, this is a direct statement to Norman Mineta:

You're a fucking idiot. End of story.

Now go away, K. (Norman, not the rest of you :)

So, when the U.S Secretary of Transportation has just taken away my >> instinctive << fight-or-flight >> instinct << thats been with me, and every other human on this planet, since day one, and furthermore my right to self defense from a >> "reckless << whatever (papparazzi, random phreak from the street, crazed-ex girlf..." uh, never mind... I didn't say crazed... you may have read crazed, but I didn't mean in the ... um, uuhhhh.... ummmm...

so, well, anyway... :D MOVING ON!)

So, when the aforementioned gov official has taken away the above mentioned human instincts, and above mentioned right to self defense... to then state:

"It's irresponsible to compromise the safety of a child for the sake of the moment."

Ummm... when you say "for the sake of the moment"... does that include *all* moments, no matter what the circumstances happen to be?

For example, lets say someone is chasing after me with a gun, threatening to kill me. At that point would it be better for me to jump in my car with my son on my lap, not as concerned as I would normally be by the fact that hes not in his car seat, and a little more concerned with getting the hell away from the dude who wants to blow my head off?

Yuu know what? Don't answer that please... I'm scared to know the answer.

Hey Norman, you've got some serious issues there buddy... In fact, I think we can safely state your issues have issues, and still have only just broke the issue surface.

Seek help. Uh, wait...

First... step down. Then seek help.

And keep your hands where I can see them K Norman.

Thanks.

---

So while I keep my eye on Norman "The Issue Inflicted Grandstand-er" Mineta over here ("keep 'em up where I can see them there Mr. Mail, err[1] Mineta"), let me finish this off...

So, when we have reached a stage where even the U.S Secretary of Transportation is taking away our civil rights in a public setting, using the press to perform this illegal act of communistic root, I think we can safely state "its time for a change in government officials."

Like all of them.!!! Just rip them all out, and start over from scratch.

It might not be any better as a result.

But it sure the hell couldn't get any worse, that's for DAMN sure!
---

[1] : Please don't take that as a intended slam against Norman Mailer, and instead a simple connection between Mr. Mineta and the content of some of Mr. Mailers titles, some eye opening stuff for sure if you havent had the pleasure of reading any of Mr. Mailers novels, journalistic short stories, or combination thereof. If that happens to be the case, you might consider visiting his Wikipedia page above and crack open your favorite online or visit your favorite real-time book vendor and consider picking up a few of his titles. Good reading, and eye opening at the same time.

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

A Tragedy? A Triumph? In The End, Its Up To You...

Dare Obasanjo aka Carnage4Life - Why IE 7 Can't Import OPML Files from RSS Bandit

Recently there was a question asked on the RSS Bandit forums from a user who was Unable to Import RSSBandit-Exported OPML into IE7. The question goes

... just like every other question to every other feed reader forum on the planet...

"Why can't I import/export my OPML files!!!???"

The answer:

OPML is not only *not* XML, in many ways it's not even text!

So here's this particular poor unfortunate victim's story:

I exported my feeds from RSSBandit 1.3.0.42 to an OPML file in hopes of trying the feed support in IE7. IE7 seems to try to import, but ultimately tells me no feeds were imported. The exported file must have over a 100 feeds, so it's not that. Has anyone else been able to import feeds from [deleted RSSBandit as this applies to EVERY feed reader] into [deleted IE7 as this applies to any attempt whatsover to try and make sense of that OPML nastiness!]?

Apparently Dare was able to get some info from the IE7 folks:

I got an answer for why this is the case from the Internet Explorer's RSS team. The reason is provided in the the RSS Bandit bug report, Support type="rss" for export of feeds, where I found out that somewhere along the line someone came up with the convention of adding a type="rss" attribute to indicate which were the RSS feeds in an OPML file. The Internet Explorer RSS team has decided to enforce this convention for indicating RSS feeds in an OPML file and will ignore entries that don't have this annotation.

*THANK GOD!!!* Maybe this will finally be enough to get people to start looking for other ways to gain access to their stored feed index inside 'XYZ' feed reader. I've pointed at Uche's post regarding his IRC-based community open forum research project to seek out a replacement for OPML .several times before, but if I knew that it would ultimatelly lead to the death of OPML, I would build a bot to make a post every hour on the hour, on every blog I am currently active in making posts to which, at present time, is six.

What would the post say? Well, similar to an OPML file, it would be a series of random glyphs that had no rhyme, reason, order, or any other recongizable pattern of any sort that would then state:

Each day 100's of millions of glyphs like those pictured above are ripped away from their friends, family, and loved ones and forced into a life which can be described in no other way than that of the ultimate anti-life, the darkest of all dark-matter, the bitter gall of Hell's own fury:

OPML.

Yeah, I know... it's hard to even think about...

I'll give you a moment to collect yourself.

[MOMENT]

Be strong my friend, be strong!

[DEEP BREATH]
[HEAVY LONG EXHALE]
[SHED A TEAR]
[PULL IT BACK]
[SNIFF]
[COLLECT YOURSELF]
[PAUSE]
[and...]

For the price of fifteen minutes taken from your lunch break, you could write a parser that could mean the difference between life...

And OPML.

All it takes in one click.

One click and you could help save the life of *MILLIONS upon MILLIONS* of glyphs who would otherwise be thrust into that that bitter bit bucket of no return; the bit torrent black hole from Hell; Thats right:

/dev/null

And yet some say they have it lucky! In fact many have begged for a such a wonderful ending to such a tragic story, for they know that if not /dev/null then this can only mean something much more awful, much more painful, a much slower, darker, nastier, and horrific end to a life that once held so much hope! To just such a life, what they now face is altogether the ultimate insult to any good God-fearing glyph with any sense of dignity, pride, who once lived a life of romance and passion, with dreams of fulfilling their life's destiny of living inside the glorius pages of a wonderful, glorius book who's pages will be read from over, and over, and over again, bringing a new spark of pride each and every time the eyes of their reader is emblazened with the glory of their printed impression. Instead, they now know that its only a matter of time before they face:

The Windows Recycle Bin.

HAVE YOU NO SHAME!!!!!!!!!!! MAKE THE FUCKING CLICK!!!!

Thank you for your support.

What a tragedy. And to think, you.

YES YOU!

YOU could help turn this potential tragedy into a powerful triumph over the Evil one Itself:

OPML.

Please make the click. Uche's Web Server is standing by.

Make the click.

Thankyou.

Posted by m.david at 04:30 PM | Comments (0) | TrackBack

February 18, 2006

So Then You're More Concerned With Your User Derived Profits Than Your Users Privacy?

[UPDATE: Micah, thanks for the reminder! My default search provider has now been properly set to Yahoo!, a much better search engine to rely on (and no doubt it's getting better by the day! :D) for my daily search needs. Please see my follow-up comments (and if you're not Micah, then obviouly reading his comment first for proper context would make sense :D) below.]

Google Criticizes Gov't in Court Papers - Yahoo! News

"If users believe that the text of their search queries into Google's search engine may become public knowledge, it only logically follows that they will be less likely to use the service," Google's lawyers wrote.

Hey Google:

* You're Grandstanding.
* Did you just state "it only logically follows that they will be less likely to use the service"
* Just checked. Yeah, you did.
* if (MSFT == EVIL) && (EVIL == 'Profit without moral conscience') then (apparently, anyway) (MSFT != EVIL) && GOOGLE does.
* if (you just chuckled 'silly lad, that won't compile') then (thanks for proving my point)

[UPDATE: How would that prove my point? If, in fact, Google's response was to try and point out problems with something that had nothing to do with the point of the post, and was, in fact, just frivolus nonsense that doesn't add or take away from the overall value of the point, then they would making an attempt to derail my point by simply changing the subject to something completely unrelated.

So why put it there in the first place?

"You're new to these parts, aren't ya..." ;) :D

So how would attempting to change the subject to something unrelated prove my point? If, in fact, this was proven to be their response, then it would showcase the fact that they're not concerned with their appearance of evil and in fixing that apparance if its proven to be a false image of what is truly the case.

It's doubtful.

But I'll leave room for the possibility that they're lawyers are the evil ones. If this proves to be the case.... fire them. They're making you look evil. If you're not, then prove it by finding council that are not criminally minded, and are truly concerned with protecting the privacy of your customers, instead of the profits of your corporation.

Pretty simple. In fact, here's a little quote you can tack to your "bulletin board" as a reminder:

If the privacy of your customer base is put first, profit will come after.

If profit is put first, it will be your last.

or, as has been foretold in the scripture of centuries past:

The first shall be last, and the last shall be first.

Think about it.

Recursion (or, in this case, tail recursion) is not a theory of Computer Science, nor is it a theory in Physical Science.

Recursion is a God-like trait that has been woven into the Cosmos since further back than we have the ability to measure. It's part of the 'Grand Design', although, like art and poetry, I'm not so sure the 'Grand Design' was in fact a design the way we think of design, and instead, an understanding.

In fact, this showcases quite nicely that Religion and Science have a lot more in common than most Far Right & Left Wingers, respectively, would be willing to both accept, and admit.

It's too bad... So much peace and tranquility can come into your life when you stop trying to push your own designs and instead understand the designs that already exist... which in fact, taking the above into account, would mean that understanding the design isn't about design, and instead, understanding.

See. 'Recursion all over again.'

or is it 'Again over all recursion.'?

Yep. It's Both.

You hate me now don't you?

Yeah. Welcome!

Oh, and don't forget... membership fees are due before the last day of each month!]

[Original post continued...]

Hey Google, here's a clue:

Three other companies have handed over this information and have done so without a user uproar in privacy concerns. One of those companies is Microsoft. Another, a company in which you own 5%.

So, what's the problem again? Oh, that's right, you're more concerned with looking like the hero, and in return get LOTS AND LOTS AND LOTS of GREAT FREE PRESS!

BTW... Was this the kind of "GREAT FREE PRESS!" you were looking for?

Probably not, huh?

Here's an idea:

How about we change some of those words around to read something less like an evil, profit driven corporation who's profit, above all else (like morals, etc...), is of the most importance, and concerns over their users privacy plays the role of 'second fiddle'. How about something like:

"If users believe that the text of their search queries into Google's search engine may become public knowledge, it only logically follows that they will be less likely to feel that their privacy is just that, private." Google's lawyers wrote.

NOTE: It's kind of too late to change it now. Your true colors have already shown through. Stating "yeah, that's what we meant to say." isn't going to work.

What will work? Not sure. But I've already changed my default search provider to MSN Search. I'm trying to decide whether or not to dump Gmail and Google Talk. They're more an integral part of my daily dev-life, although I could easily and quickly change that if it proves necessary.

Guess we'll see if it does.

Posted by m.david at 08:34 AM | Comments (2) | TrackBack

February 17, 2006

On Procedural vs. Declarative Gardening

Over the last few days a wonderful event has been taking place in the EXSLT camp. To summarize:

* An initial EXSLT 1.0 proposal has been brought forward
* This proposal contains quite a bit of the great and wonderful things that have been developed as part of the XSLT 2.0 spec.
* A general "hand shake" agreement has taken place to move forward with extensions to the XSLT 2.0 spec, creating both an EXSLT 1.0 for XSLT 1.0 and an EXSLT 1.0 for XSLT 2.0 recommendation from the EXSLT group.
* Several major obstacles have been overcome resulting in all of the above being made possible.

However, not everyone is really all that satisfied with the current state of affairs, concerned that this effort takes away from XSLT 2.0 and the hard work put forth by the W3C:XSLT-WG.

I disagree. Here's why:

One who comes from an "XSLT 2.0 ROCKS!!!!" standpoint, I must admit that I initially set out about 8 months ago to convince Uche and others in the Python/4Suite world to build an XSLT 2.0 processor.

In that time, here's what I have discovered:

They don't want one.

Why? I don't think it really matters why, but I think a snippet from some comments made yesterday by Sylvain to the EXSLT list should help shed some light on the matter:

It was the time I was working with C# and .NET for my job and Python + Amara for my personal projects. Well, I would welcome more XSLT 2 in an environment such as J2EE or .NET because programming languages such as Java or C# do not have the same flexibility as Python, Perl or Ruby. To me it looks like XSLT 2 is more an attempt at fixing the lack of flexibility of the former. (Note that I do not mean to say C# or Java are weak or bad languages but I suspect their static nature is the root of their lack of flexibility in our context).

Like the W3C:XSLT-WG folks (most particularly Dr. Kay), I have a *TON* of respect for the Python/4Suite folks. When I set forth on the above mentioned quest, little did I know what the actual result of this 6+ month quest would be:

I've fallen for Python.

Don't get me wrong... I plan to use every bit and piece of XSLT 2.0 coupled with IronPython and C# via Saxon.NET, a project I have become pretty attached to as well ;)

I must admit, however, that I find it interesting that what was originally a push to convert the Python/4Suite community to XSLT 2.0 has instead resulted in my own conversion to the Python language.

Over the last 72 hours those of us subscribed to the EXSLT mailing list have witnessed what I believe to be a *FANTASTIC* compromise by several die hard folks from both camps. The fact that the EXSLT folks are open to the development of an EXSLT for XSLT 2.0 spec, and that several heavy hitters in the XSLT 2.0 camp are now standing behind both this effort *AND* the recent proposal put forth by John L. Clark and Uche Ogbuji means only one thing:

*THIS IS GOING TO HAPPEN*

Several folks have stressed concerned that this shows disrespect to the W3C-XSLT-WG.

But in reality it has nothing to do with disrespect for the W3C-WG and all the work they have done, and everything to do with providing extended value to the existing XPath 1.0-based XSLT language. In fact, a lot of the work the W3C-XSLT-WG has done has directly influenced the contents of the aforementioned spec. The fact that much of XSLT 2.0 has found it way into this initial proposal for EXSLT 1.0 suggests that these folks respect the work the W3C-WG has done, not the reverse.

It seems to me that all of this boils down to two action items:

* Continuing efforts to extend XSLT as a Domain Specific Language.
* Ensuring that the XSLT communities (1.0, 2.0, EXSLT 1.0) stick together, appreciating XSLT for what it is, no matter the version or extension family.

Few would ever suggest that Lisp is anything less than a *SPECTACULAR* language. XSLT is derived from DSSSL and DSSSL has its roots in Lisp.

How many variations of Lisp are there?

Not sure. I know there's a lot! Given the fact that Lisp is such a wonderful language, the fact that XSLT seems to be following in the footsteps of its forefathers to me suggests good things, not bad.

However, while Lisp is making a comeback in a *BIG* way, the biggest obstacle these communities are facing at the moment stems from the fact they let the family run wild for a bit too long without as much as a Family Reunion every couple of years to at very least catch-up on old times. As such these camps are finding the need to either start the family tree over from scratch (Arc) or attempt to find the best branch (Scheme) and graft themselves back into the main root 'system' (sorry... It was there. ;).

Of course there is a core group of folks who are standing firm on the notion that the core Common Lisp family roots is where the clean-up effort should be focused, headed by none other than Peter Seibel who has likened this effort to gardening -- see: http://lispniks.com/cl-gardeners/

I like Common Lisp. I like Peter Seibel. No disrespect is meant when I state what they are attempting to accomplish isn't about gardening... What they're attempting to do is plough an old farmers field that has long since been paved over and a mall built on top...

And they're attempting this with a horse plough!

While I commend these folks for their efforts, and really hope they gain some much needed traction, I don't envy them. It seems to me that we (speaking in terms of the collective XSLT communities) can either follow directly in the steps of our ancestors and as such find ourselves scrambling to re-band 10 years from now with our horse ploughs, scratching our heads as to why the soil is "SO DAMN HARD!", or we can learn from their mistakes, roll up our sleeves, pick the weeds, and work at keeping the "family" together the best we can. Our family may be showing signs of growing pains, but at least we're still happy and the growth taking place in fairly healthy soil.

If we do a good job now, there may be hope for our little Domain Specific Garden yet... But I don't think its time for the lime bags just yet and instead gardening gloves, pruning shears, rake's, shovels, fertilizer, and a bit of old fashioned nurturing.

I don't think its any accident that Lisp took on the 80's hyped roll as the de facto language for Artificial Intelligence. Intelligence suggests the ability to differentiate. To think through a list of choices, and choose one option over the others, and to do so both logically and, for the most part, accurately.

Intelligence is a human characteristic (at least its supposed to be anyway ;) With its roots in choice, coupled with the nature of being human, intelligence also promotes free will. Humans, by nature, have a tendency to rebel against the norm... especially when they are told they *MUST* do something a particular way. These characteristics --

* intelligence showcased through free will
* our tendency to tell people "you must do it this way, or you are wrong"

can be related to two styles of programming:

* Declarative, in this case, "Provide me with enough information, then let me choose my own path"
* Procedural, in this case, "It's my way or the highway!"

Tying this back into the notion of gardening:

* Declarative Gardening - "I would like a garden. Here are some elements. I can't wait to see the results!"
* Procedural Gardening - "You'll grow how I tell you to grow, and you'll like it!"

Telling our XSLT garden how to grow isn't going to work the way we think it will, if in fact we believe that fighting against the 'system' (what can I say, everything *IS* a system :) is going to end in the result that we expect that it will.

It won't.

Intelligence will choose its own path (XPath? :D).

Just like it *wasn't* designed to.

I leave you in peace:)

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

February 16, 2006

IronPython 1.0 Beta 3 Now Available

IronPython: News item

Hello IronPython Community,

We have just released IronPython 1.0 Beta 3. This release is primarily a bug fix release as we drive towards IronPython 1.0. Unfortunately we didn’t get to review the PythonEngine APIs in this release but will be getting this done for the next beta.

We also continue to work on improving CLR and Python interop. In this release we’ve added support for an assembly path (clr.Path) for assembly dependency resolution. If you’re currently using clr.AddReferenceToFile(‘…’) you’ll need to modify these calls to update the path and then add a reference without a full path (this will ensure dependencies get resolved in an orderly fashion). We’ve also improved our array support, adding both slicing operations for arrays and a new array creation syntax: System.Array[int]((2,3,4,5)) will create an integer array with the values 2,3,4 and 5.

Finally we continue to advance standard Python compatibility with the addition of a few new built-in modules: struct, codecs, and marshal. These are some of the most-requested modules from the community.

You can download the release from: IronPython Beta 3 Download

The rest of this new release as well as the list of bug fixes are below:

contd.

We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: allenwb, Flexibal, Giles Thomas, glchapman, Hector Miuler Malpica Gallegos, Shigeru Hemmi, Jesse Kaplan, John Platt, Matt Beckuis, Michael Shilman, Michael Twomey, Mike Hostetler, mrwizard82d1, Nicholas Jacobson, Paparipote, Ravi Terala, Sanghyeon Seo, Stanpinte, Thomas, and Vargaz.

Thanks and keep in touch,
The IronPython Team

More complete list of changes and bug fixes:
============================================

Python CodeDom generator, parser, and compiler implemented
Bugfix: string.split() throws incorrect exception
Bugfix: Compiled module not initialized properly when imported
Resource support for the compiler
Bugfix: Compiler throw on invalid syntax
Many parser fixes for handling invalid syntax
Improved test support for running tests in multiple modes
Bugfix: Exception.args cannot be accessed from Python code
Bugfix: sys.exc_info()[1] in except block yields CLR exception instance, not Python exception instance
Bugfix: Data from exception does not capture all arguments
Bugfix: sys is missing sys.byteorder
Built-in function enhancements
Bugfix: Ctrl-C support in Console
Bugfix: __str__ not working on new style classes
Bugfix: implement –x command line parameter
Bugfix: Do not generate EXEs and PDBs as by-products by default (-X:SaveAssemblies overrides)
Bugfix: Meta-classes not doing the right thing in some cases
Bugfix: RE_Pattern.finditer() requires optional arguments
Bugfix: re.groupindex() returns non-empty dictionary even w/ no symbol groups
Bugfix: Context not flowing to compiled code when executed with eval
Bugfix: Null reference exception in PythonEngine.DumpException
Bugfix: sys.LoadAssemblyFromFile() should search sys.path for the specified assembly (searches clr.Path)
Bugfix: Dynamic overloading of ReflectedMethod’s is broken
Bugfix: Displaying a multi-dimensional array with lower-bounds is broken
Bugfix: Conflict between IList and overloaded indexers
Bugfix: list w/ a key isn’t a stable sort
Bugfix: built-in functions shouldn’t ever be bound
Bugfix: ReflectOptimizer can now properly distinguish between methods & static functions
Bugfix: Finish cleanup of caller context changes
Bugfix: typo in lambda
Bugfix: NewTypeMaker single object array params may have adverse affects on keyword / params args
Bugfix: Inheriting from built-in type damages super type
Bugfix: MakeNew collisions resulting in unverifiable assemblies w/ NewTypeMaker
Bugfix: Python class subclassing .NET class: constructor weirdness?
Tutorial includes information on creating events from Python
Bugfix: Eval still leaks for many corner-cases
Bugfix: problems with exec
Bugfix: exec doesn’t use proper environment in a class def
Bugfix: Unable to remove event handlers completely sometimes
Bugfix: List comparison fails with class instances
Bugfix: Display floats w/ lots of precision correctly
Bugfix: Import __main__ raises ImportError
Bugfix: Implement _codecs built-in module
Bugfix: Precision field not used with string-formatting codes
Bugfix: Can’t access globals from inside exec running in the class body or function
Bugfix: String subclass test in string_tests.py is disabled
Bugfix: Should be able to use a CLR Hashtable or Dictionary<> to provide keyword bindings of arguments using the ** operator
Bugfix: vars() -- TypeError: vars() argument must have __dict__ attribute
Bugfix: When keyword argument and unpacking argument lists together...
Bugfix: For functions of arity >= 6, called with wrong number of arguments, the TypeError reports the actual number incorrectly
Bugfix: Iron Python Exceptions need to be marked serializable
Bugfix: list of lambdas only evaluates first expression
Bugfix: ReflectedProperty.__set__ does not check for setter==null before checking setter.IsStatic
Bugfix: Support mapping key in string formatting operation
Bugfix: Equality comparison for slices is broken

Posted by m.david at 04:35 PM | Comments (0) | TrackBack

February 15, 2006

On Saxon Diaries

Michael Kay starts Saxon Diaries

Here's an interesting resource. Michael Kay's new Saxon Blog promises to be a good resource for anyone using Saxon XSLT.

Excellent!

I noticed also that someone pinged Edd Dumbill regarding this fact, and as such you can access Dr. Kay's feed from Planet XMLHack.

This too is excellent!

Want more excellency? (You're getting it whether you want it or not, so here's hoping the answer was 'yes' :D):

I've also started a blog of which you can be the first reader!

[WW:Ether: What's that? You mean you were the first official reader of Saxon Diaries?]

Yep! I'M THE KING OF THE WORLD!

[WW:Ether: No, your just the first official reader of Saxon Diaries]

Aren't these the same thing?

[WW:Ether: No.]

Hmmm. Thought they were. Well, in my world, they're the same thing.

[WW:Ether: So you're the King of you're own World?]

Ummmm... Hmmm... Well... Ummmm....

Yeah, I guess. But can we just pretend it's for the whole world?

[WW:Ether: No.]

Hmmm. Damn!

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

Yet One More Example From The Folks @ Opera For The Other Browser Vendors To Follow

Desktop Team - by Desktop Team

The release of Opera 9 Preview 2 marks the start of a new tradition: The Weekly Builds. Every week until the final version of Opera 9 is ready, we intend to ship a weekly updated version of Opera 9 on this blog.

The goal is to further open up our development process to our devoted users and allow you to be more involved at an earlier stage than when we ship the next public beta.

The Weekly Builds are snapshots, they are not as thoroughly tested as a Technology Preview or a Public Beta. You should only use these builds if you are not afraid of losing data (e-mail, bookmarks, anything) or crashing your computer.

First weekly builds (Windows, Mac, no Unix yet) available here.

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

A Picture Of A Fork

Miguel de Icaza

And this is what a fork looks like:

:D

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

On Office Live and What Microsoft Does 'Get'

Microsoft Monitor: What Office Live Is Not

From Dare Obasanjo I found the above linked article. A quick snippet:

Microsoft is probably more concerned about a Salesforce.com than a Google here. Microsoft's core business is applications and operating systems. Services like Salesforce.com negate the value of both applications and operating systems, territory Microsoft won't easily cede. It's no coincidence that CRM is a major Office Live feature.

There's a *TON* of great soundbites in this post that help answer a lot of questions as to whether or not MS 'gets it' or not.

Take away: They do.

Posted by m.david at 05:16 AM | Comments (0) | TrackBack

February 13, 2006

Hacking IE7 : Does IE7 Prefer The Atom Data Feed Format?

[UPDATE: On irc://irc.freenode.net/#atom channel, Aristotle Pagaltzis points out that he has seen the point of this post brought out on (possibly) the IE7 blog. Couldn't find it in an initial search, but if someone like Aristotle suggests this to be the case, you can be pretty close to absolutely certain he's correct. Your comfort level that this will continue into the final release should be increased appropriately.

Thanks Aristotle! (update: Artistotle has located the source he was refering to on the RSS Team Blog. Please see his comments below. This might seem like a silly thing to some of you, but it's the little things like this that enable the ability to create a better overall experience for your future site visitors. Rarely do you hear people complain about anything other than the little annoying things that drive them nutts about a site. In fact, the GreaseMonkey craze helps showcase this point quite nicely. It seems to me that most GreaseMonkey scripts do one or two little things... written by folks who were fed-up with the way a particular site was dealing with this, or that, or whatever else. Little things matter. Thanks again Aristotle!)]

By pure accident I noticed that it seemed that if given a choice, IE7 will choose Atom over RSS if both formats exist as 'AutoDiscovery' html/head/link[@type='application/rss+xml' or @type='application/atom+xml'] elements in an html document. [1] After running through a few tests, however, it seems that in fact this is not the case.

What does seem to be the case?

It seems to pick the first one on the list that it understands and sets the default value of the orange data feed AutoDiscovery button to the @href value of this element.

So when a visitor visits a web page in which declares any combination of <link rel="alternate" type="application/atom+xml href="..." ... /> or <link rel="alternate" type="application/rss+xml href="..." ... /> elements inside of html/head, the orange icon will "light up". [2] If they click the orange icon button instead of the 'dropdown' to the right (which will give them a list of all declared html/head/link[@type = 'application/atom+xml' or @type = 'application/rss+xml'] elements) they will be served up a formatted version of the data feed that is associated with the first html/head/link element on that list, in document order.

In what should be a pretty obvious point, the way to ensure that folks in which visit a domain//page under your control are served up the data feed format you prefer (If not obvious from prior posts, I'm a *BIG* fan of Atom!) if they click the orange icon instead of the dropdown...

Put whatever that might be as the first link element in document order in which meets the proper attribute="value" criteria.

Not sure if this will continue forward and find its way into the final release of IE7, but it makes sense for MS not to play favorites so I can't imagine it will change. However, to play it safe, this portion is definitely a 'wait and see' game.

In the mean time, however, if you're comfortable with the notion that this might change and if you have a preference over data feed formats and/or you want the default value to be set to, for example, the full content instead of partial content or vice-versa, then simply place that particular link element at the top of the <link rel="alternate" type="application/atom+xml" href="..." ... /> or <link rel="alternate" type="application/rss+xml" href="..." ... /> stack and you should be good to go.

At least for now, anyway. ;)

Enjoy!

---
[1] : Tim Bray should be happy to hear that <link rel="alternate" type="application/xml" href="..." ... /> is not recognized as a data feed format, even if you use a fairly obvious data feed name such as 'atom.xml'...

[2] : Good thing they chose to follow the lead of Mozilla/Fx... makes it nice and easy to notice when a page declares one or more of the above *AND*, to a geek like me, its obvious what is represented by the icon. Now we need to see how well that translates to the average *non-geek*.

Posted by m.david at 03:24 PM | Comments (2) | TrackBack

eXplorations Episode #4 : Can Google Really Beat Microsoft : Now Available For Download

ChannelXML Community Blogs | M. David Peterson : Free Kurt Cagle (and save me from his wrath while you're at it)!

via the above linked entry, the intro to latest edition of eXplorations begins:

In what was meant as an innocent 'shout out' to Sylvain (turns out both of us are *BIG* 'Queens of the Stone Age' fans) it seems that I may have invoked a spell upon Kurt, and now theres *ALL HELL* to pay!

I didn't mean to do it. But the Devil, err, I mean Kurt, made me!

Help save Kurt Cagle! Episode #4 of eXplorations is now available for download : MP3 Format : WMA Format

---
[RunningTime:Intro (:Start ~ 00:00 -> :Stop ~ 2:25) Total = 2 minutes 25 seconds ]
[RunningTime:Discussion (:Start ~ 2:25 -> :Stop ~ 20:35) Total = 18 minutes 10 seconds ]
[RunningTime:Finale (:Start ~ 20:35 -> :Stop ~ 23:47) Total = 3 minutes 25 seconds ]
---
[RunningTime:Complete (:Start ~ 00:00 -> :Stop ~ 23:47) Total = 23 minutes 12 seconds]
---

[Podcast Data Feed]

Posted by m.david at 01:54 PM | Comments (2) | TrackBack

February 12, 2006

JsonT - Transforming JSON

JsonT - Transforming Json

Such that I can access this again a bit easier when I have a few minutes to check it out, I've copied the supplied code below. To ensure proper licensing is kept in place I have copied over the copyright and licensing info as well. However, if you plan to blog about this and/or attempt an implementation of some sort to then blog about it, please make sure you point back to the original source.

Thanks!

Copyright and License info followed by the code is below:

Here is the javascript function jsonT(data, rules), which transforms any JSON data data by applying the rule set rules.

You can download the most current version and a test page here and may use it freely under the Creative Commons GNU LGPL License.



function jsonT(self, rules) {

   var T = {

      output: false,

      init: function() {

         for (var rule in rules)

            if (rule.substr(0,4) != "self")

               rules["self."+rule] = rules[rule];

         return this;

      },

      apply: function(expr) {

         var trf = function(s){ return s.replace(/{([A-Za-z0-9_\$\.\[\]\'@\(\)]+)}/g, 

                                  function($0,$1){return T.processArg($1, expr);})},

             x = expr.replace(/\[[0-9]+\]/g, "[*]"), res;

         if (x in rules) {

            if (typeof(rules[x]) == "string")

               res = trf(rules[x]);

            else if (typeof(rules[x]) == "function")

               res = trf(rules[x](eval(expr)).toString());

         }

         else 

            res = T.eval(expr);

         return res;

      },

      processArg: function(arg, parentExpr) {

         var expand = function(a,e){return (e=a.replace(/^\$/,e)).substr(0,4)!="self" ? ("self."+e) : e; },

             res = "";

         T.output = true;

         if (arg.charAt(0) == "@")

            res = eval(arg.replace(/@([A-za-z0-9_]+)\(([A-Za-z0-9_\$\.\[\]\']+)\)/, 

                                   function($0,$1,$2){return "rules['self."+$1+"']("+expand($2,parentExpr)+")";}));

         else if (arg != "$")

            res = T.apply(expand(arg, parentExpr));

         else

            res = T.eval(parentExpr);

         T.output = false;

         return res;

      },

      eval: function(expr) {

         var v = eval(expr), res = "";

         if (typeof(v) != "undefined") {

            if (v instanceof Array) {

               for (var i=0; i
                  if (typeof(v[i]) != "undefined")

                     res += T.apply(expr+"["+i+"]");

            }

            else if (typeof(v) == "object") {

               for (var m in v)

                  if (typeof(v[m]) != "undefined")

                     res += T.apply(expr+"."+m);

            }

            else if (T.output)

               res += v;

         }

         return res;

      }

   };

   return T.init().apply("self");

}