In case anyone has an interest in the wonders of mother nature here is an album of pics I took of Mt. St. Helens, Rainier, and Adams (some random pics mixed in) - St.Helens was showing a little attitude that day and puffing a stream of steam… definitely some fun shots for all the family to enjoy ;)
http://xsltblog.com/mtsthelensadamsrainier/
Cheers!
<M:D/>
Posted by m.david at 12:23 PM | Comments (0) | TrackBack
** <COMMENT-MDP>' ** Please read all the way down, or at very least scroll there now if you dont want to read all this code. Gaston has left the door open for desingers to jump in and develop something other than what he has as his base XSL Transformation file. I've bolded the XSL related portions of this post.
** </COMMENT-MDP> **
* In general Refresh is not needed anymore; I’m parsing when the XAML tab page is activated.
* Rob told me that the viewer could not parse some valid files (for example when the XAML file had codebehind). He helped me with a solution for that so that this is working now. Thanks Rob
* Chris Sells suggested add the Visual Tree to the viewer and he pointed to this post that shows how to do the work. I accepted the suggestion and I had implemented this feature in this way:
o I changed the base code in this way:
public static class VisualUtility
{
public static void GetVisualTreeInfo(Visual element, XmlWriter writer)
{
if (element == null)
{
throw new ArgumentNullException("element");
}
writer.WriteStartElement("VisualElement");
writer.WriteElementString("Type", element.GetType().ToString());
VisualCollection vc = VisualOperations.GetChildren(element);
if (vc != null && vc.Count > 0)
{
foreach (Visual v in vc)
{
GetVisualTreeInfo(v, writer);
}
}
writer.WriteEndElement();
}
}
o The difference is that this code write the visual tree in XML.
o I was thinking in read this XML and show it a tree view (winform), but I’m learning XAML now!! So I decided to use a XSL in order to generate XAML.
When the visual tree tab is selected the XML is generated and after that the visualtree.xsl is applied in order to get a XAML (in a MemoryStream) and then load this XAML in the tab page. (the tab page has a ElementHost in order to show XAML inside a windows form)
I’m not a graphic designer so I hope that somebody modify my initial visualtree.xsl (it is in the installation folder) to get a better XAML for the Visual Tree. Now it is just a XAML Table.
---
Ummmmm.... thats sounds like a tempting offer! Hmmm... Well, if anybody else would like to take Gaston up on this please do so. If at the end of the day my task list is complete and no offers have been made to make this stylesheet the phattest little stylesheet Visual Studio has ever seen then I may just have to jump in on this one... none-the-less, if you have the cycles today and what to get some recognition from the folks in Redmond, this would be a GREAT opportunity to do so... In fact, what am I thinking... the more styles the merrier folks... HAVE AT IT!!!! :D Please let me know if you do submit a new stylesheet to Gaston so I can make sure it gets blogged.
___
What brings me to near tears of joy is the recognition to the fact that instead of using .NET's XML editing API's Gaston, without even a hesitation, realized that he needed to be using a XSL stylesheet for this tool and as such created one and made it the focus of this application to render the XAML within the code viewer.
For you Visual Studio developers (don't be ashamed, I use it too... ;) this seems like a nice little addin for viewing your XAML base in Markup, Text, and as a Tree View. Cool! [NOTE: This is a Whidbey >> Visual Studio 2005 only add-in]
Posted by m.david at 05:22 AM | Comments (0) | TrackBack
Fox Sports Interactive Media Selects Sarvega’s XML Speedway Accelerator for FOXSports.com on MSN
Posted by m.david at 08:48 PM | Comments (2) | TrackBack
From a recent email from Dimitre,
Hi David and Oleg,
I am sorry I’m on a trip and will be back only on Friday.
I wanted to provide something for the Myths dispelled (what XSLT “can’t” do), but this will have to wait a little.
The blog is really great!
Cheers, Dimitre.
Thanks for your support and compliment Dimitre! I know that I for — well, what will probably amount to everyone who reads this blog — anxiously await your first entry into the “Disspelt Myths of XSLT” category.
I know there are a lot of you out there that have great examples for this area. I encourage anybody and everybody with a sample (code would be nice but in cases like my first entry into this category a few days ago obviously its not mandatory) to send it to me either via email - m.david@x2x2x.org - or via comments.
Cheers!
<M:D/>
Posted by m.david at 02:44 PM | Comments (0) | TrackBack
Heres the last 3 lines of an IM conversation I just had with Brian...
cluebyfour: and it's true we use a fair amount of xslt, mostly to format the results and other xml responses from the app, but it's all done via embedded controls in the aspx pages
mdptws: Oh cool... so you do use some XSLT then?
cluebyfour: yep, all behind the scenes of course . . . but i wrote an entire contextual help engine using xslt. almost like old times :D
Once again the viral effects of XSLT are made apparent, this time embedded directly into ASP.NET application pages and server side controls...
Thanks for the clarification Brian!
Posted by m.david at 02:28 PM | Comments (0) | TrackBack
Given the last few sentences of my last post I found it funny to discover the name chosen by the Movable Type engine for the archived html page… I won’t point it out, instead leaving it to you deviant types (of which I am one in the same) to discover for yourselves… :D
Cheers!
<M:D/>
Posted by m.david at 02:17 PM | Comments (0) | TrackBack
I always find it a pleasure when I visit a web site that was designed and developed by those who understand good layout and design principles and subsequently put them into practice. I worked with a group of folks a while back in Colorado who somehow all seemed to “relocate” to the same company a few miles to the east of where we all originally worked together. While I migrated back to Salt Lake and Seattle they all stuck together and have built a pretty phat little company over there in Englewood, CO. It’s called Groople and from time to time I find myself pinging my old manager Brian Martinez (an old-time frequenter of XSL-List — in fact you can still find his mark on the list as he still holds the first spot on the first page of the FAQ stressing the importance of list etiquette) just to see what he’s up to and to reemphasize to him my evil plan and devious ploy to recruit him away at some point in the future — great manager, great developer, stands his ground, gets the job done… you know, the kind of guy you actually enjoy working for and with :).
Well it seems Brian has just finished up the layout work and underlying code-set that attaches into the backend of Groople’s booking engine — a marvel in and of itself - I know this because…. well, I just know this and they know why I know this and I guess for now thats all that matters :)
Now you might be saying “and this relates to XSLT how”? Well, beyond Brians connection to the list I believe that in many regards the XSLT developer population is closely connected, if not directly, to the design teams at many development firms. What comes from the mind of the designer must then be “interpreted” by the developer and a plan formulated on how to render the necessary data into the specified design format. Obviously the code being rendered in this case is a combination of HTML and CSS that, more likely than not, has its rendering roots, be it on the server or the client (well, most likely the server — hopefully this will be changing soon :) in a library of XSLT stylesheets. So while the connection may not be obvious from the outside those of us who know better are all shaking our heads right now saying “uh huh, yep.”
Now I should point out the fact that Groople’s site, from what I understand, doesnt have a whole lot of XSLT being used behind the GUI rendering scenes, if any. But this has everything to do with the fact that the application behind Grooples booking engine is built on .NET and Web Services and the original design of the system focused more on the components of ASP.NET to render a majority of the content for the site. So, simply put, static HTML templates and CSS files coupled with ASP.NET server side controls did exactly what was needed. And when something works you’re not even going to find me arguing that they should have used XSLT instead, especially given my passion for the .NET framework.
But I do know one thing… Brian is fully aware of the power that lays at his fingertips in XSLT. We just had a brief conversation on the state of client-side transformation capabilities and I think I can safely say that he was happily surprised to find that it was further along than he may have realized. I’m hoping that the sample file and tutorial I plan to publish here in a bit will help further enlighten and intrigue just enough to bring him to call upon his XSLT heavy past and start playing around with various possibilities with client-side rendering of both layout and data — who knows, maybe its the grasshopper who will be teaching the master this time ‘round ;)
Cheers Brian! Congratulations to you, Ed, Ty, and the rest of the Groople crew who have put together a fantastic example of web layout and design done right.
On a side note (directed at the Groople crew), recent events have led me to think its just about time for a trip to CO to pay a visit to my old buddies while at the same time cruz’ on up to Boulder to buy a beer and groove to some tracks with a new one. It seems that, for whatever reason, something is always drawing me back to Colorado ;) I’ll tell you what it is… its those Colorado women… OOooooooohhhh mama, gotta love them Colorado women… oh wait, this is a family blog.. sorry, kids!!! I best get back to work… :D
Posted by m.david at 01:04 PM | Comments (0) | TrackBack
A very good friend of mine and partner in crime on what is becoming a plethora of open source projects including AspectXML (this is what brings it slightly on topic) has reached a pretty significant milestone today. Russ Miles, Aspect-Oriented Software Development Extraordinaire, Java Guru, and the hackiest hacker that would make any hacker parent proud has had several chapters of his new (and first) book, AspectJ Cookbook, printed online at OnJava.com for your reading/viewing pleasure.
Direct from the email I just received from him (Careful, the bits may still be a little hot… click with caution! ;) )
http://www.onjava.com/pub/a/onjava/2004/11/24/aspectjcook-2.7.html
On java.net:
http://today.java.net/pub/a/today/2004/11/22/Aspects.html
Even some beta chapters on the publishers site:
http://www.oreilly.com/catalog/aspectjckbk/index.html?CMP=ILL-4GV796923290
Congratulations Russ! You have definitely made your U.S.-based counterpart green with envy… All be it a good green envy as it definitely inspires me to push forward with some of my own projects that have been set aside to allow room for other things… I think I need to set some other things aside and get back to it…
Cheers my friend! Congratulations once again :) Can’t wait for the printed copy!!!
<M:D/>
Posted by m.david at 07:01 AM | Comments (0) | TrackBack
GiMLaB � XML-FO Making XML Look Good in Print
Well lookey here… Our own Dave Pawson is having blog entries focused on his XSL-FO book… In spanish none-the-less…
According to Babel Fish the translation of the comment from spanish to english is:
“It is not a book for nascent. Sample in detail in standard XSL-FO. Few examples.”
Given that I have a hard enough time using the proper “there”, “their”, or “they’re” in my sentences (I promise I know the difference. I just tend to type faster than my human grammar and spell checker can process and it tends to get left behind… :( ) I had to look up “nascent” at dictionary.com (apparently it was word of the day on Dec. 15th 2001 for those who find triva like this interesting)
Although there are seven entries I guess the one labeled Main should be the one we use:
Main Entry: na·scent Pronunciation: ‘nas-&nt, ‘nAs- Function: adjective 1 : coming or having recently come into existence : beginning to develop <neuroblasts migrating into a nascent ganglion> <the folding of nascent polypeptide chains> 2 : of, relating to, or being an atom or substance at the moment of its formation usually with the implication of greater reactivity than otherwise <nascent hydrogen>
In further tyring to interpret what this author is suggesting it seems that he/she feels this book is not for those who are first getting started in XSL-FO. That’s funny… It seems this is the same theme found in the comments on Amazon… hmmmm….
Dave, what are you trying to do to us… make us smart? ;) :D
This is a fantastic title. And I will agree that its not for the beginner looking for a tutorial on XSL-FO. But I don’t think Dave intended it to be anything even remotely resembling a tutorial so I am guessing (I really am, I have never brought the subject up with him before…) he probably takes these statements as compliments. This is a technical book for technical people looking to add XSL-FO to their quiver of knowledge points. If that is you… BUY THIS BOOK!!!
Posted by m.david at 06:46 AM | Comments (0) | TrackBack
In a recent post to XSL-List the ever insightful Dave Pawson responded to a question in regards to case conversion of element and attribute names. A combination of suggestions were originally presented including:
<xsl:template match="foo | Foo">
...process
</xsl:template>
While this is a solution that works well for a manageable (read: limited) number of possibilites it doesn’t scale — in other words it doesn’t take long before this solution becomes more of a code management nightmare and a performance bottleneck for the processor.
<xsl:template match="*[translate(name(), 'ABC..', 'abc..') = 'italic']">
<!-- Yuck... -->
</xsl:template>
I think the authors (Geerst Josten) comment that exists where the typical “processing code goes here…” speak for itself. While I haven’t tested this particular idea it seems like it could logically work… but the yuck comes when you are running a translate function on every node that falls through the template base looking for a home… something Geerst was obviously aware of.
I guess DaveP took pity on both the questioner and the not-so-helpful solutions Geerst and I offered up as he brought out something I did’nt even know existed until now….
That DaveP always has a trick or two up his sleeve (either that or I need to spend some quality time with the FAQ again… hmmm…)
http://www.jclark.com/sp/sx.htm
Inserted Comment[MDP]: This text comes from the SX site.
“SX converts SGML to XML. SX parses and validates the SGML document contained in sysid… and writes an equivalent XML document to the standard output. SX will warn about SGML constructs which have no XML equivalent.
-x xmloutputoption
lower Prefer lower case. Names that were subjected to upper-case substitution by SGML will be folded to lower case. This does not include reserved names; XML requires these to be in upper-case.”
so sx -x lower will do the translation you want, producing lower case tags.
HTH DaveP
As always Dave, it does :)
Posted by m.david at 02:24 AM | Comments (0) | TrackBack
One of the things that always amazes me is how often I come across developers who have both good taste in music and a tendency to be musicians themselves. While I can’t speak to the musician side of things it seems Uche Ogbuji is no exception to this generality. In a follow-up to a prior post (see the piece entitled “Mars in Scorpio rampant”) Uche mentions Karmacoma and Massive Attack although stops short of explaining what that means. To someone like myself who has a deep root of both appreciation and feelings towards the music that came from Bristol, England (or was directly influenced by this music) during the early to mid-90’s (right smack dab in the middle of the grunge to post-grunge era, or Pearl Jam to Matchbox Twenty for those of you still scratching your head :) I completely understand what Uche was suggesting with his reference to a timeless classic of electric poetry and the poets in which brought this poem into being, expressing thoughts I think we all could learn a valuable lesson from, if not more. There is an emotion that is stirred when listening to the likes of Tricky, Portishead, Massive Attack, Faithless, and a few other groups and musicians (or mixtures thereof) that can not really be described in words as it is an emotion that can truly only be felt. To this day the flow that starts with “Reverence” (from Faithless::Reverence), continues with “Don’t Leave” and (my personal favorite) “Salva Mea” and moves through to “If Loving You Is Wrong” is a flow that I turn to on a regular basis to get my own flow moving (the rest of the tracks are amazing as well although this particular sequence tends to ignite the flow.) Karmacoma is a member of this same class which expands into tens of hours of tracks with equal if not greater tendency to inspire at times of inspirational poverty in my life.
I realize musical preference is a personal thing. What I feel to be a foundation of soul defining poetry may sound like irritating noise to you. But the beauty in this difference is that the foundation of music is built where science, art, poetry, and human emotion co-exist which in many ways is the same place a true blue hacker finds his or her inspiration for the code he or she writes. If this same intersection of multi-dimensional points existed in the same location for all of us I have a feeling things would begin to get a bit crowded and boring and we would all probably look to other means for inspiration and definition of being fairly quickly. Confinement to the traditions of society is something I think we all tend NOT to conform to; yet one more common trait of the Hackers and Painters Paul Graham so elegantly and accurately defined in his recent O’Reilly release of the same title.
Thank God this intersection does not exist in the same place… and yet with that said its always nice to find a fellow hacker who has found inspiration from a source that is similar, even if that similarity begins and ends at this same intersection of personal dimensions the end point in which will eventually become our own unique, and ever changing definition of personality and individual traits.
Cheers Uche! It seems we may have at least one other thing in common… the prior commonality made apparent in our obvious shared tendency to let our astrological personality profile find common ground with our actual personality profile - whether we want it to or not. Personally I would’nt want it any other way… at very least this trait tends to make life a bit more interesting from time to time. :)
If I did’nt make it more apparent in my previous post let it be said now… You were correct in being irritated by my post. You’re arguments were spot on. I jumped the gun and I should have been more careful in reading what you had said prior to posting the code snippet. My apologies for this obvious oversight and subsequent tounge lashing. It was undeserved and like you said, unfair.
Best regards,
<M:D/>
Posted by m.david at 01:47 PM | Comments (2) | TrackBack
Problem with comments is now fixed. While they have always been received it was’nt obvious given that a) an error was being returned. b) I have “Moderate Comments” turned on to keep from comments spammers being able to post.
Posted by m.david at 04:01 AM | Comments (0) | TrackBack
It seems the same problem that has plagued the UnderstandingXSLT site has now propogated to this site. Please be advised that although it may not seem like it your comments are being received and as soon as I can make sure that they are not comment spam I will approve them for posting on the site.
Hopefully I can get to the bottom of this problem soon. In the mean time please know that your comment has been received even if it doesnt seem like it.
Thanks!
<M:D/>
Posted by m.david at 02:26 PM | Comments (0) | TrackBack
In going to XML.com and looking at the articles written by Uche Ogbuji it seems there is a lot of really good content here for those interested in learning more on the subject of Python and XML. Sorry Uche, but being someone who is just now learning about the benefits of Python I have never read any of your articles and had no idea you were such a prolific author on this subject.
I also did’nt realize you were part of the 4Suite project at FourThought which I have had earmarked for a while to learn more about. Maybe its time now that I do that :)
Cheers!
<M:D/>
Posted by m.david at 02:18 PM | Comments (0) | TrackBack
In all fairness I feel I should clarify some comments I made on the Python and XML/XSL/XPath post from a few days ago. My intention was’nt to post the article so I could then come back and slam the author for what I felt was bad use of XPath syntax. If I post an article it will always be because I feel the overall content is worth reading.
This article, overall, is a good read. While I still hold to the ideal that we as authors and self proclaimed experts in a particular technology have an obligation to propogate good usage and syntax of code I now realize that my comments may have been seen as an attack on this article or author overall. That was’nt my intention and apologize if in any way this is the message that was taken from my posting.
As I said, overall its a good article and worthy of your time to read it.
Cheers!
<M:D/>
Posted by m.david at 01:59 PM | Comments (2) | TrackBack
Llucifer’s weblog � Blog Archive � Use Jelly XLF:FO and FOP to print and generate PDF
I haven’t taken the time (and probably won’t) to look at this more deeply but from a quick glance it seems interesting and worth the read. If you test any of the code and find anything interesting please post back a comment and let us all know…
Thanks! :)
Posted by m.david at 02:10 AM | Comments (0) | TrackBack
Posted by m.david at 02:03 AM | Comments (0) | TrackBack
Ze Vanvean Blog � XSLT ? CSS ?
I don't speak French but Google does!
Posted by m.david at 02:00 AM | Comments (0) | TrackBack
This is mostly .NET specific but worth the read none the less.
Just for fun heres a picture of Don at the XML DevCon with Becky Dias and company...
Posted by m.david at 01:56 AM | Comments (0) | TrackBack
Digital Encyclopedia: Discussion topics for the Digital Encyclopedia Workshop
Posted by m.david at 01:48 AM | Comments (0) | TrackBack
Digital Web Magazine - An Introduction to Client-Side XSLT: It’s Not Just for Server Geeks Anymore
Pretty basic intro and tutorial but its good to see that the trend towards client-side XSLT stylesheet transformations is moving forward in several industries.
Posted by m.david at 01:38 AM | Comments (0) | TrackBack
In a recent post to XSL-List Andy Dent wrote:
“I found that studying a bit of Scheme to learn recursive thinking helped HUGELY with XSLT - I recommend “The Little Schemer” which is a set of “exercises for the brain, like piano finger exercises”.
coping with XSLT syntax is painful enough without also struggling to understand the semantics!”
This is an excellent post. Thanks Andy!
A quick Google search and I found that this title is published by MIT Press (one of my favorite publishers!) and can be found in their online catalog as well as on Amazon.
The extension to this title, The Seasoned Schemer, can be found and purchased from MIT Press and Amazon as well.
I am a BIG FAN of Lisp and Scheme (a Lisp derivative) and am in fact working on the development of LispML (http://www.lispml.com — very long term, not a big priority for me at the moment) which will be a way of writing Lisp using markup to take advantage of all the great XML tools out there as well as validate against a given schema for proper usage that is then “compiled” to Ansi Common Lisp using XSLT for further compilation to a specific platform. I’ve never seen this title before but will most definitely add it to my list of “MUST READS” as I believe that its not to far down the road that Artificial Intelligence will become a bigger portion of our programming life and as such languages such as Lisp (considered by many to be the defacto development language for Artificial Intelligence) will be making a big SPLASH on the development scene. I find it ironic that a language with roots that date back to the mid to late 50’s era — and as such at the very beginning of computer language development — will more likely than not become the foundation of a lot of the programming we will be doing 10-15 years from now if not sooner.
For those unfamiliar with Lisp (link different than above definition link), Scheme(as is this), Haskell, or a number of other Functional Programming Languages I would highly recommend taking some time to learn one or all of these. If for no other reason understanding the foundation of Functional Programming will help in your day to day programming of second generation semi-functional languages like XSLT 1.0 and more fully functional compliant languages like XSLT 2.0 and XQuery. As per Dimitre Novatchev’s XSLT & Functional Programming papers you can learn more about the specifics as to what determines whether or not XSLT can be considered a Functional Programming language. In fact given Dimitre’s update to the XSLT 2.0 code base of FXSL on SF.net earlier today it seems a very appropriate time to add this to your list of “things to study” for the week as Dimitre has created and absolutely fabulous foundation of high-order functions that can be implemented immediatelly in your XSLT code by simply importing the stylesheets and calling the imported functions directly.
Posted by m.david at 08:34 PM | Comments (0) | TrackBack
It drives me nutts when I see this statement being made and for some reason I seem to see it all the time (maybe that would explain my crazy behavior from time to time ;) ). XQuery IS NOT a superset of XSLT 2.0. It IS a superset of XPath 2.0. In fact, XPath 2.0 and XQuery 1.0 share about 80% of the same specification content. XQuery 1.0 CAN NOT do everything and more that XSLT 2.0 as the word “superset” would imply. While it could easily be argued that there is very little, if anything, that XQuery can do that XSLT 2.0 can not do in one form or another (elegance is not a requirement for this comparison) I will leave XQuery alone on this as I do believe that it does have its place in the world of XML software development.
However, please, if you ever hear anybody make such a statement that is so grossly mis-represented as to suggest XQuery is XSLT 2.0’s superior please send them my way and I will make sure that they are set straight on the matter. :)
Cheers!
<M:D/>
Posted by m.david at 07:27 PM | Comments (0) | TrackBack
As per another suggestion from Dimitre I am sending out a call for code and content to showcase areas in which it has been propogated throughout the software development world that XSLT was incapable of performing a particular programming task only to be proven wrong by example.
If you have an example you would like showcased please either post a comment or email me directly — m.david@x2x2x.org — with a title/subject for the myth and the subsequent code proving that myth wrong.
Looking forward to your entries into this category!
Best regards,
<M:D/>
Posted by m.david at 07:15 PM | Comments (0) | TrackBack
As per a suggestion from Dimitre Novatchev (excellent idea, thanks Dimitre!) I have added a XSLT “Quote of the Day” section to the site.
I will do my best to keep this particular section filled with interesting quotes. However I very much doubt that I will be able to locate enough content on a daily basis to keep this filled on my own merits. As such I ask that if you have a particular quote you feel should be listed in this section please email it to me, listing the source of the quote and any other details you feel important. While I can’t guarantee anything I will do my best to make sure that each quote sent to me is given proper air time.
To ensure that you don’t have to visit the site to view the XSLT “Quote of the Day” I will add it as an entry each day as well as list it on the right side column to add a bit of interesting contrast to those who do visit the site.
Cheers!
<M:D/>
Posted by m.david at 06:59 PM | Comments (0) | TrackBack
As per a recent post to XSL-List by Dimiter Novatchev:
"It appears that Sourceforge.net contained an older version of FXSL for XSLT2.
The latest version has been apploaded -- thanks to Colin for alerting me.
Cheers,
Dimitre."
The new stylesheets can be found at the FXSL project page on SF.net:
http://sourceforge.net/projects/fxsl/
Thanks Dimitre! As always you're work in this area is greatly appreciated by many, many members of the community :)
Posted by m.david at 02:22 PM | Comments (0) | TrackBack
Applying XSLT to XML Using ASP.NET
Posted by m.david at 12:57 PM | Comments (0) | TrackBack
Per my last post to XSL-List in response to a post by xptm@sapo.pt
“Actually, I think I may have what you are looking for. In my spare time I have been working on a cross browser implementation that uses a combination of XML data islands, XML data files, and XSLT 1.0 stylesheets coupled with client side javascript to pass variables to the stylesheets which then use these variables with the document() function to access new data files to transform. Its part of a project that I am implementing for a client so I wont be able to show it to you as is… but as soon as I have a chance I will break open the code base and pull the non-client-specific files out. I can then put in some foo xml files to showcase whats going on.
When I’m done I will reply back here and on post the files to xsltblog.com for the consumption of anyone interested in this method. I doubt highly I will get to it today but I should have a chance sometime before Monday to put it together and publish it.”
Cheers!
<M:D/>
Posted by m.david at 12:22 PM | Comments (0) | TrackBack
I have plans to create Bio's for each member of the "Legends of the XSLT Community" that have links to each area of the listed members involvement in the XSLT community. I will be doing this over the coming week and will make an announcment to their availabilty as soon as I am finished.
Posted by m.david at 08:44 AM | Comments (0) | TrackBack
In a recent post to XSL-List Colin Paul Adams released the following:
"I've just uploaded the documentation, plus an alpha-test binary for
Linux (built and tested on Fedora Core 3 - may well work on other
Linuxes) to sourceforge.
I'm not releasing a windows (or ,NET) binary yet because:
a) I shall have to ask someone else to build it, as sourceforge does
not include Windows as one of the platforms in it's compile farm, and
b) Windows local file name support isn't working yet (but you can
always type URLs instead).
If there is enough flak on gestalt's mailing list (accessible from
sourceforge), then I guess I might be persuable.
If there is any demand, I can probably build other binaries, provided
sourceforge has the platform in it's compile farm (I noticed solaris,
Mac OSX, freeBSD and Debian, I think).
The home page is http://gestalt.sourceforge.net/
-- Colin Paul Adams Preston Lancashire"
---------------------
This is fantastic! I love the fact that so much effort is being made by individuals of the XSLT community to bring support for XSLT 2.0 to the rest of us.
Thanks Colin!
Posted by m.david at 08:39 AM | Comments (0) | TrackBack
Posted by m.david at 07:50 AM | TrackBack
XML.com: Location, Location, Location
Article seems fairly informative. If you are considering Python as a possible base development language for your XML and XML tranaformation related projects this seems like a decent code-based sample overview.
There are a few little annoyances I’ve noticed. I’ll document them in the extended portion of this entry.
One of the more annoying things I come across in code samples is when authors use XML/XPath/XSLT that, while technically it will work, is simply just bad form and should not be propogated to people who may be new to the technology and end up picking bad habits up (that will eventually come back to annoy me again at some point… what an awful cycle.. bllaaahhh!)
Heres a perfect example…
<?xml version="1.0" encoding="iso-8859-1"?>
<labels>
<label added="2003-06-20">
<quote>
<emph>Midwinter Spring</emph> is its own season…
</quote>
<name>Thomas Eliot</name>
<address>
<street>3 Prufrock Lane</street>
<city>Stamford</city>
<state>CT</state>
</address>
</label>
<label added="2003-06-10">
<name>Ezra Pound</name>
<address>
<street>45 Usura Place</street>
<city>Hailey</city>
<state>ID</state>
</address>
</label>
</labels>
/labels[1]/label[1]/quote[1]/emph[1]/text()[1]: text node with value “Midwinter Spring”
Ok, can you see my point.
First, whats the position selector doing at the root element “labels”. Theres only one root element (not to be confused with root node… search the archives or look at DaveP’s FAQ to understand the difference) of a well-formed XML file and given that “labels” follows on the next line after the “<?xml snip…” declaration the “its an XML fragment… there can be many labels within this document” isn’t going to fly.
Second, there is no text node that is a child node of “emph”. The text contained within the “emph” element is the value of “emph”, not the value of a text node that is a child of “emph”. Theres a text node in this sample that is a sibling of “emph”. So you could use something like:
/labels/label[1]/quote[1]/emph[1]/following-sibling::text()
… this would be a nice way to showcase how you would access the value of the text that follows the “emph” element. Notice I took away the [1] that would specify the first text node sibling of “emph”. There can only ever be one text node following-sibling (or preceding-sibling for that matter) of any element as the parser sees everything after the “>” of the closing element and before the “<” of the next opening element, if anything but white space exists (well, that would depend on the processor to be completey accurate but no need to bring that into play as this point… DEFINITELY worth its own blog entry at some point though!), as one long string of text which it dubs a “text node”.
Well, enough annoying code for one day… I’m headed off to bed… Got a Thanksgiving Day Turkey Bowl to attend in the morning. For those wondering what I mean by Turkey Bowl it refers to an annual football game played every year on Thanksgiving morning by your local crowd of weekend warriors which, over the years, I have sadly become. Chances are there is a Turkey Bowl planned for somewhere near your home… a park, a school ball field, wherever theres somewhere that can somehow be dubbed a make-shift football field chances are good there will be a really bad game of football being played on it;s surface tomorrow morning… I’m going to start taking Ibuprofen now so I can ease into the pain later… :)
<M:D/>
Posted by m.david at 09:01 PM | Comments (3) | TrackBack
While off-topic this is something I consider to be quite exciting as it allows developers the ability to use CSS the way it was designed and not the way IE feels like handling things (or not handling them as the case may be.) See http://dean.edwards.name/download/ and click the “IE7” file download image. The nice part about this is that the fix is written in jscript and can be included in your pages so it doesn’t (from what I can tell) require any user action from your site visitors for the functionality to work.
Also noticed on this same site a XBL file to bring IE DHTML behaviors to any Mozilla based browser. For those of us who have switched to a Mozilla-based browser but miss having some of the cooler DHTML features available in IE: now theres an answer.
Posted by m.david at 12:17 PM | Comments (0) | TrackBack
From my post to XSL-List…
“I wanted to send out a quick invitation to anyone and everyone interested in following along and participating in my adventure to better understand XSLT from the ground up. As I am sure a lot of you can attest its easy to let the little details in the features of a language get lost in the cracks along the way. From time to time it seems that a good way to re-discover these little details and fine tune your skill set is to start back at the beginning and work all the way through to the end, picking up the little pieces of lost understanding along the way. I know that in the past this has been an effective method for me to become a better programmer in other areas of development. So I think the time has come to do it again, this time in the study of XSLT.
The site in which I will be blogging this adventure is http://www.UnderstandingXSLT.com. The book I will be using is Jeni Tennisons title “Beginning XSLT” from A Press. I have a link on the site to the title on Amazon.com. I also have a request in to Jeni (through my last post) to let me know if there is any other link she would prefer me to link to on the site. If for some reason the link on the site takes you somewhere else besides Amazon.com, this will be why.”
Anyone interested in this I will see you over at http://www.UnderstandingXSLT.com. I plan my first post (beyond the “Welcome” post) for Friday morning.
See ya there :)
<M:D/>
Posted by m.david at 11:38 AM | Comments (0) | TrackBack
In the early development of the LLUP project we have been trying to decide what standards we should build on top of. While from the very beginning we had pretty much decided that ATOM would be our base we kept from attaching ourselves to anything until we have weeded out what needs to be a part of LLUP, what doesnt need to be a part of it, and why. Once this has happened (will be happening soon) we can then figure out what standards we can best build from given the core feature-set that we settle on. Well, if my mind was 99% set on ATOM before its 99.100% (read 99 point 100%: yeah, I realize its technically 99 point 1% but when the phrase is spoken its meant to convey the idea of absolute while allowing for the possibility that it may not be...) set on it now... At the XMLDevCon, after Tim Bray spoke to some points in regards to the reasoning behind designing XML architecture a certain way (in regards to I believe the ATOM specification but I can't be certain) Tim Ewald stood and proclaimed "Right On Brother!!!" in a thundering proclamation that only Tim Ewald himself could reproduce.
As Tim Bray finishes his posting... "You don’t think this can change the world? Just watch."
To make no attempt to even try and reproduce Tim Ewalds proclamation I will simply stand behind him whole heartedly as he unsuredly will be making the statement again soon... "Right On Brother!!!"
Posted by m.david at 08:17 AM | Comments (0) | TrackBack
XML straining network performance, bandwidth
Here's an article thats help better bring into light the reasons why solutions like binaryXML are being considered. Interesting stuff!
Posted by m.david at 06:28 AM | Comments (0) | TrackBack
PRESS RELEASE: Adeptia Releases the XML Mapper for Easy and Rapid Data Integration
Seems interesting. I'll try to take some time over the holidays to download and play with this a bit and see what value may or may not exist for the XSLT developer.
Posted by m.david at 06:17 AM | Comments (0) | TrackBack
As I mention at the bottom of the "Legends of the XSLT Community" list the list is not exhaustive. In fact, over the next few days and weeks it will continue to grow at a fairly rapid pace. My goal is to create a blog entry as to the reasons why I feel someone is deserving of being considered a legend within this community and then open it up for comments so that others can ring in as to why (or maybe in some case why they feel I am wrong) they feel this person should be considered a legend.
So, from the standpoint of my reasons for adding Oleg to the list:
- EXSLT.NET (if this was all it would be enough!)
- nxslt and other .NET related XML tools
- Overall contribution of wisdom and expertise to beginning, intermediate, and advanced XSLT developers alike.
- Continued contributions to advance the support for XSLT 2.0 on the .NET platform through the XQP project.
Welcome to the list Oleg!
Posted by m.david at 05:24 AM | Comments (0) | TrackBack
In a comment made to my last post regarding the idea of an XML obsfucator Oleg Tkachenko asked the question “Why not just zip the file?”. Good question. Why don’t we just compress the XML file for transport and uncompress it when it arrives? If speed of delivery is the primary driving force behind binary XML then I completely agree with Oleg… why not just compress the data? Actually, I guess from the standpoint of storage (another reason I have seen for the justification of binary XML) compression of the file should also be sufficient.
Comments?
Posted by m.david at 05:15 AM | Comments (0) | TrackBack
It seems that once again the subject of binary XML is taking center stage. While I can understand the desire to optimize wherever possible I wonder if the time wouldnt be better spent building an XML obsfucator that would, in essence, parse an XML file and obsfucate the element names and attribute names and related namespaces down into single or double character compilations with an associated mapping file that would be used to run the all related XSLT files against this mapping and adjust accordingly (ooooh.. that could be a potential disaster!) or use it as a real time mapping (definitely less chance of mucking things up by simply matching the obsfucated name to the related name in the map and not making any changes, but still not a totally accurate approach, I think…? Maybe I will just have to try it and find out.) Obviously XML files have a tendency to beome fairly large, especially when caution is not used in naming conventions. An argument could easily be made that by obsfucating an XML file and reducing its overall footprint you are making every portion of its processing faster… from faster delivery times of the data (smaller means faster in the case of the web) to faster parsing by the XML parser as well as faster transformations by the XSLT engine or DOM API, etc… The data would obviously stay the same but the data is not at the base of the binary XML argument… speed, storage space, transport of data, etc… are definitely at the forefront of justification for using this format.
So then would obsfucation of an XML file (retaining a map to transform it back if necessary or map it to the XSLT designed for the original usage) make more sense simply because it retains the text nature of XML and as such doesnt require new parsers and processors that ultimately perform the same function, just slightly faster than the text-based counterpart?
It seems to me this would be a much more realistic approach to solving the issues of reduced size and processing time while requiring no extra effort on the part of the vendor to build yet one more parser for yet one more file format.
Thoughts?
Posted by m.david at 10:49 AM | Comments (2) | TrackBack
In response to a post I made suggesting it was impossible to use an XML parser to parse XML that was not well formed and more specifically that two well formed XML docs that are concatenated as one document would create one non-well-formed document Wendell posted this solution would should be documented both for posterity and for the fact that its a kick-butt solution!
As always….
via Wendell Piez, Nov. 22nd, 2004 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Depending on what’s actually in the two-or-more concatenated XML documents in a single file, it may constitute a well-formed external parsed entity, and can be parsed as such.
That is, if we have in dox.xml (which does not parse as XML):
<?xml version='1.0'?>
<doc>...</doc>
<doc>...</doc>
<doc>...</doc>
the entirety can be parsed if it is called into a shell or “wrapper” document like so:
<!DOCTYPE wrapper [
<!ENTITY content SYSTEM "dox.xml">
]>
<wrapper>
&content;
</wrapper>
… which can be parsed (and processed with XSLT, which could be used to split the pieces back out).
If there are XML declarations sprinkled throughout, as in
<?xml version='1.0'?>
<doc>...</doc>
<?xml version='1.0'?>
<doc>...</doc>
<?xml version='1.0'?>
<doc>...</doc>
… then you have to work a little harder. (Some less-than-conformant parsers may not care about those errant XML declarations, thinking they’re processing instructions; but most will.) Pre-processing to remove or alter them would work, but if you could identify them dependably, you could as easily split the files at that point and not have the problem. (You could alter them to something innocuous like a PI, parse the file and then use XSLT to clean up the mess, but that would be embarrassing: I wouldn’t announce it to the list if I were planning that.)
If the demarcators aren’t XML declarations but really PIs:
<?xml version='1.0'?>
<doc>...</doc>
<?separator?>
<doc>...</doc>
<?separator?>
<doc>...</doc>
then it would work to wrap the file into an entity.
That is, how hard you have to work very much depends on the particulars of the format of the concatenation.
Have we been told exactly those particulars?
Cheers, Wendell :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Thanks Wendell!
<M:D/>
Posted by m.david at 07:53 PM | Comments (0) | TrackBack
For those of you interested in helping to shape the potential future of communication over the internet please visit http://www.llup.org to learn more about LLUP, the Limited [Lifetime|Location] Ubiquitous Protocol - The Other Side of Push.
Posted by m.david at 05:11 PM | Comments (0) | TrackBack
Not that I am knocking Schematron... Absolutely love it, especially given its XSLT implementation roots. Daniel Cazzulino gave a fantastic demonstration of Schematron for .NET (He was the primary developer, I believe, for this particular Schematron implementation) at the Applied XML DevCon last month. But I have to wonder how such a vibrant shade of pink was chosen as a major portion of the theme used on the technologies main site. Is there a story behind this? Would love to hear from anybody with insite into this...
Beyond the choice of theme colors you can't knock the technology so be it as it may I guess I'm just going to have to live with it... Doubt much that my personal opinions are going to sway the minds of the designers all that much so I guess I'll focus on whats good about Schematron (A LOT!!!) and not on the chosen color scheme.
Cheers!
<M:D/>
Posted by m.david at 09:42 AM | Comments (0) | TrackBack
Most of you already know about this but its definitely something important enough to post for those who are unaware.
Posted by m.david at 08:31 AM | TrackBack
XMLMania.com - FILES - Xml2PDF formatting engine version 2.1 released
Posted by m.david at 08:28 AM | Comments (0) | TrackBack
Mark Logic and Stylus Studio Announce Partnership
Posted by m.david at 08:27 AM | Comments (0) | TrackBack
Posted by m.david at 08:25 AM | Comments (0) | TrackBack
XML Strengths and Weaknesses with DOM ASP and XSL
I sometimes forget that I have been working with XML and related technologies since way back in the day (circa 1996) when I first started working with the Site Builder Network and the Channel Definition Format they were responsible for promoting. According to Tim Bray CDF was the first XML-based implementation (the original XML Working Draft was published, as far as I know, on 1996.11.14) to hit the streets sending champagne corks a-flying over at the old W3C. [OT NOTE: Thinking back to those days reminds me that I need to track down and old friend of mine Kerry Woolsey who took over my position on the SBN team when I left to work for the Windows CE team -- If anybody knows how to get a hold of him please let me know...] I loved the CDF technology but I think its safe to say we were all a bit happier to be rid of the channel bar that suddenly appea