PLEASE NOTE: Regarding the title: iSorry. ;-)

So anyway, Sylvain arrived here in the U.S. of A. on the 13th,

… and the two of us have been heads down ever since preparing to release this at that. The day before his arrival I paid a visit to my local Apple Store to pick up his development machine. As such, he too is now discovering just how wonderful development life on a Mac can be.

Of course as wonderful as life can be there is one thing that has really irked me: The lack of a good tabbed shell/terminal client. What surprised me is that no matter how hard I looked it didn’t seem like anybody either noticed and/or cared enough to do anything about it. But as Sylvain just discovered, apparently I was wrong,

iTerm

iTerm is a full featured terminal emulation program written for OS X using Cocoa. We are aiming at providing users with best command line experience under OS X. The letter i represents a native Apple look and feel of the program interface, and an emphasis on complete international support. iTerm was merged from two projects, CTerminal and TerminalX, both of which were based on JTerminal project. The current version is still in beta stage. It is however very much functional and usable.

SWEET! I feel like I just rediscovered Firefox!

Thanks, iTerm developers! :D

Since publishing my recent article on Next Generation Grid Enable SOA and taking this topic out into the world, I have been getting asked to clarify and frame the discussion around why state management in what is supposed to be “stateless” SOA is such an important issue. Steve Jones of CapGemini bluntly stated No they ruddy well shouldn’t be when he wrote his opinion on stateful vs stateless services in a SOA.

My observation has been that the need for state management is a continuum that ranges from completely stateless to fully stateful services as the complexity of the business logic and the longevity of the service instance increases.

Since joining Oracle I have been working across the various product teams in the Fusion Middleware Group, to create a vision for what I’m currently calling “Next Generation Grid Enabled SOA”. I recently published an article on the subject in SOA Magazine.

In my blog Converting Content Models to Schematron I outlined some code ideas. Recently we (Topologi) have been working on an actually implementation for a client: a series of XSLT 2 scripts that we want to release as open source in a few months time.

Why would you want to convert XSD to Schematron?

The prime reason is to get better diagnostics: grammar-based diagnostics basically don’t work, the last two decades of SGML/XML DTD/XSD experiences makes plain. People find them difficult to interpret and they give the response in terms of the grammar not the information domain. And error messages are reported in terms of where the error was detected, not where the error was. For example, given a content model (a, (b, c)?, c, d ) and a document <a/><c/><c/><d/> you will get an error “Expected a d” at the location of the second c element; however the problem really is that the b is missing.

Schematron converted from a grammar still does not have much info to go on. Of course, the Schematron scripts should be easier to customize for tailored assertions and diaganostics. But also the phase mechanism is very useful: we can implement multiple different ways of checking the grammar and let the user decide on which one provides the best information.

A secondary reason is that Schematron only needs an XSLT implementation. There is still quite a suspicion that XML Schema implemantations are partial or broken. Japan Industrial Standards’ comment on Open XML were that they could not in fact even get the Schemas to run under Xerces and another major implementation. XSLT is much more common. However, we have decided to use XSLT2, and SAXON in particular, because it offers us some short cuts.

One shortcut that is quite fun is this possibility (I am not sure whether we will implement this method this round, it is outside our initial brief): by converting the children element names of an element into a string, such as “H1 p div div div table ht p” for example, and the converting a grammar such as ( (H1 | H2 | H3 | P | div | table )* into a regular expression equivalent, we can actually use the built-in regex recogniser of the XPath2 functions to validate the document. Just using a vanilla CSLT2. And this even copes with the minOccurs/maxOccurs cardinality contstraints, too.

This is rather exciting as these things go because it means that we can have a fallback validator that completely covers all the constraints of a grammar system, without leaving Schematron or the world of assertions. The downside? If implemented in a simple way, you only get the same kinds of diagnostics as a conventionally implemented XSD system will give you. But the advantage of having a complete Plan B means that we can concentrate on useful messages for the Plan A.

I’ll blog on how we implemented it over the next few weeks. Basically, we have a two-stage architecture: the first stage (3 XSLTs) takes all the XSD schema files and does a big series of macro processes on them, to make a single document that contains all the top-level schemas for each namespace, with all references resolved by substitution (except for simple types which we keep). This single big file gets rid off almost all the complications of XSD, which in terms makes it much simpler to then generate the Schematron assertions.

We have so far made the preprocessor, implemented simple type checking (including derivation by restriction) and the basic exception content models (empty, ALL, mixed content), with content models under way at the moment. I think the pre-processor stage might be useful for other projects involving XML Schemas.

Actually, the difficulty has been in an unexpected direction. XML Schemas is so unpleasant to work with, that one programmer asked to be take off the project because it was simply too much to cope with, and another has left the company (to take up an overseas appointment) but not before also getting frustrated, boggled and bogged down by XSD! Things like complex type with simple content derived by extension from a simple type with simple content etc become a maze or ratnest. (Hopefully we have that under control and we’ll be able to attend to our backlog of other work ASAP: we have been pretty poor.)

It is interesting that in all the last almost eight years of Schematron, I don’t recall anyone complaining it was too difficult. Instead, I regularly get surprised to hear of quite important projects where it has been quietly used without fuss or drama, and just chugs away doing its thing, with everyone involved feeling (and being) in control. This week for example I heard about UK taxation office’s use of Schematron for checking incoming documents being lodged. I think some of the reason for the success might be that because Schematron is small, it can be kept under control and understood, and that because there is zero support from the large software players, it is never used as part of an attempt to up-sell big hardware or message busses or protocols or enterprise systems etc.: it gets used for POX (Plain Old XML) sites.

The bumpy ride to ISO standardisation of Microsoft Office Open XML is receiving a lot of attention here on XML.com, and drawing out a lot of strong opinions on both sides of the issue. Frankly, the intense coverage given to every minor detail in the specification bores me to tears, even though I see the need for it, and I think that there is a larger story behind these events that is not receiving enough attention.

A while back, I named Gazzag.com my enemy for spamming people to join their social network. They have a new enemy partner: Quechup.com

Quechup allows users to import contacts from their email accounts (such as Gmail). The unsuspecting user, provides their login, and Quechup does retrieve their contacts. It then sends an email to every one of those contacts from the user telling them that the user has requested them to join Quechup.

This is annoying and just plain wrong.

Some people will say that users should be more careful about sharing this information with a website, or that they should read the fine print more carefully. However, I reiterate my claim that no reasonable person will want a site to email everyone they know. We all have professional or personal contacts that we would not choose to invite to a social network. I don’t believe that even a giant, dedicated, flashing warning page that alerts users to the fact that all of their contacts are about to be automatically invited in their name is sufficient. This practice, as I said before, is just evil.

I assume the people who run these websites believe that they will automatically get lots of new members by spamming users’ contacts. Instead, they create a lot of angry users who go out of their way to email their friends and actively discourage them from signing up for a network.

Users develop trust in a website for many reasons. Some are simple - appearance, comfort with the community of people there, nice features, etc. Some are more technical - a good privacy policy, parental controls, and the like. Many users come into websites with a base level of trust. This sort of mass invitation violates that trust, and is a sure way to spread negative publicity about your site (such as this post). Users should have explicit, obvious, and protective control over who is invited in their name. By default, no one should be invited. The user should have to knowingly undertake a process to select every person they want invited.

I hope other networks learn from the mistakes of Gazzag and Quechup. The spamming techniques used by these sites is a worst practice of the social networking world.

One of the most startling aspects of the last year, to me, really shows the disruptive potential of standards: bitter enemies are hard at work making systems that also benefit their enemies in pursuit of a higher goal. A world turned upside down!

Examples include:

• MS opening up their formats and taking them to Ecma and ISO
• ODF and Sun making converters for Word
• Microsoft paying for an open source converter between OOXML and ODF
• IBM paying someone to review the draft specfication
• Open source activists reviewing the draft
• An ISO ODF editor making a big contribution to reviewing the draft
• Microsoft blogs publicizing Gnumeric, Apple software and any applications that get any kind of OOXML support

All this competition and bile channeled productively! No wonder people are freaked out. :-)

But the paradoxes don’t just mean that enemy act like friends, it seems. Friends also can get accused of being enemies. There is a very interesting post ODF vs OOX : Asking the wrong questions (hat tip to Doug) on the blog Spreadsheet Proctologist which I like very much because it brings out that ease-of-implementation is just as much (and perhaps mostly?) a question of what your starting base is (i.e. your native data structures and functions) as it is a question of what information and forms the external format provides.

But the readers’ comments include statements like Your self-annihilating devotion to Microsoft is too evident., and Just by touching MS OOXML, you are playing their pawn in the only purpose for this exercise. To kill ODF adaption and therefore the threat of Open Office and others as a replacement for Microsoft Office products. Is to laugh! Now GNU developers are pawns and devotees of Microsoft! That GNU software, ooooooh, just another Bill Gates plot!

As a side note, but related to the theme of finding strategies so to make the acts of people’s enemies as productive as the acts of their friends, I think that Stephane Rodriguez’ comments (to that blog and, just as circumspectly, elsewhere) on the calculation chain should be paid more attention to. (Sometime I will look up whether it made it to any national body comments for the BRM, I hope so.) Calc chain needs to be reviewed with the question asked “Is the base case a little too complicated still?” It is a mild and productive question: I suspect programmers would be happy if some more leeway were provided. Now whether the issue is an Office one or a DIS29500 one, I don’t know; but the issue should not be dismissed just because it was deposited by an ostensibly rabid whirlwind! Quite the reverse.

In a recent interview with Rohit Khare, Director of CommerceNet Labs, Jon Udell may have been responsible for introducing a new meme into the noosphere that will be as important in its time as AJAX was in 2004. Rohit Khare gave an influential presentation describing ALIT, which utilized SOAP messages for transferring events between systems, but in the intervening years, his thinking has shifted to a new system based not upon SOAP but upon RESTful RSS and Atom feeds, for which he has coined the term Syndication Oriented Architecture, or SynOA.

I’ve just glanced over the 3549 or so comments put in by various national bodies for the recent ballot on DIS 29500. I’ve made a table listing the countries that commented, together with their votes and whether I think most of their issues could be resolved during the upcoming Ballot Resolution Meeting next year.

The bottom line: there are a few touchstone issues that may be tricky but it is difficult to see from the comments that DIS 29500 would not be successfully fixed and approved to be an ISO standard. The particular touchstone issues I see are that spreadsheet dates need to be able to go before 1900, that DEVMODE issues need to be worked through more, that the retirement of VML needs to be handled now, and that there needs to be a better story for MathML.

Apart from these, there is a sea of details that are eminently fixable: typos, clarifications, fixing schemas against closed lists, the use of more standard notations for fields, encryption, conformance language, refactoring the spec: editorial and syntactic rather than data model or wholesale semantic changes. On the other extreme, there are various non-starters which I expect have little hope since they run counter to the rationale for the spec: adopting SVG or adding various frustrating little things in the name of compatibility with ODF (Some NBs even call for ODF’s blink element, even though blink has been removed from HTML since it can cause epileptic fits!)

You can find a full list of national votes from the SC34 website. I was pleased to see that all the issues I raised ended up in Standards Australia’s comments (it abstained on the vote, but its comments still go in the mix.)

What is in the table

The thing that interested me in this table was whether I thought each National Body’s comments could be resolved enough to change their No vote to Yes vote. I am assuming there is no point to a standard that Ecma and Microsoft could not buy into. One of most interesting documents in the collection of comments from different bodies is Ecma’s own contribution: basically they accept almost all of Japan’s technical issues (which have a lot of overlap) which augers well for many of the other changes.

So I provide a rating as to whether I expect that a National Body’s vote will be definitely no, probably no, or probably will change to yes as a result of a successful BRM. Caveat: The NB comments do provide a much clearer indication of each National Body’s thinking than just the raw Yes/No/Abstain vote (which are utterly useless in predicting a finally outcome); however, I would be a little more confident in my ratings of the NBs if SC34 or ISO had released information about which NBs had ticked the normal box that says they might change their mind if the issues were resolved. I guess you would rate me as an optimist in general about the process, but still I am not saying that all these NBs will necessarily vote yes ultimately; but there is quite a bit of commonality to the comments.

I also have columns marked “Indie” which has an X if it seems the NB undertook independent review of the specification. And one marked “Parrot” where the NB is reproducing (perhaps with some localization or sorting or selection) the material, turning the standards review process into a form-letter campaign. I have mixed feelings about parrot items: on the one hand an NB is free to consider whatever issues it likes, and some NBs have procedures that may favour the garrulous, but on the other hand it represents a hijacking of valuable review time to obsess on the same issues, rather than give fresh eyes.

The reviews that seem to me the best are those where an NB focuses on its areas of expertise or national interest: Japan is very interested in schemas, Israel is very interested in right-to-left text, Ireland is very interested in correct references, Australia is very interested in clarity, Canada is very interested in assistive technology, Tunisia is interested in the application to mobile devices, Ghana (with a large Arabic influence) is interested in IRIs, and so on. The comments that seem least useful are the parrot comments, and the ones with vague recommendations. (I expect that this is the first comments that many of the NB committees or staff have sent in, so it is a good training exercise nonetheless.)

And there are some nice touches in there, where perhaps some cultural values slip through: Switzerland’s comments are a list of problems they actually have rejected and the details why, and Jordan and Turkey both have dignified documents that explain their positive reasons. Some of the parroted comments are unnecessarily ranty, but only a few were mad: the US comments in one place want to remove OPC because it is not present in the “pre-existing binary format” but then they want to get rid of compatability elenents because they are a “museum”:..they don’t need to worry about consistency because they are voting yes anyway: some of the comments are like that, they are there to only allow the cake to be had and eaten. I expect that several NBs are not really attached to some of their comments.

The second last column is “Off-topic” which is where the NB’s comments includes material that the BRM cannot discuss. These are typically issues concerning IPR. MS needs to spend a bit more effort on this: Switzerland’s comment is really interesting on this point.

The final column marked “radical” is where a National Body’s comments include something that I think will be a challenge for MS or Ecma or ISO to support. I don’t include things like changing minor notations or providing better text explanations for things: I think the Ecma comments show a willingness to have those. However, where some change involves a wholesale alteration of the technology or its implementation, I would be surprised if it were acceptable. This is because for every nation that is voting “No” because they really prefer ODF, etc, there are two who are voting in favour because OOXML is what it is.

Country	Vote	Really No?	Probably No?	Probably Yes?	Indie	Parrot	Off-topic material	Radical
Australia	Abstain	-	-	-	X		X
Austria	Yes			(X)			X
Brazil	No			X		X
Bulgaria	Yes			(X)			X
Canada	No			X	X	X		Use DrawingML rather than VML
Chile	Abstain	-	-	-		X		Field formatting. Use MathML, Use SMIL, Use SVG, Use ODF
China	No	X						Review time
(Document 13)	?			X?				Remove VML
Colombia	Yes			(X)				OPC to separate standard
Czech Republic	No			X	X		X
Denmark	No			X	X		X
Finland	Abstain	-	-	-				Dates before 1900. Remove VML. Use MathML
France	No			X	X	X	X	Date prior 1900, remove math pending mathml3
Germany	Yes			(X)	X	X		Dates prior to 1900
Ghana	Yes			(X)	X	X		Dates prior to 1900. (replace VML with DrawingML, adopt MathML)
Great Britain	No		X		X	X		Add ODF-isms, (replace VML with DrawingML, adopt MathML)
Greece	Yes			(X)			X	Dates prior to 1900, (replace VML with DrawingML, adopt MathML)
India	No			X		X	X	Use MathML, pre 1900 dates
Iran	No			X		X	X	Dates before 1900. Add ODF-isms
Ireland	No			X	X			Dates before 1900
Israel	Abstain	-	-	-	X
Italy	Abstain	-	-	-				Reference implementation, test suite
Japan	No			X	X			Publish OPC as separate standard
Kenya	Yes			(X)		X	X	Dates before 1900. Remove DrawingML
Korea	No		X			X		Needs interoperability with ODF. Remove VML and DrawingML
Malta	Yes			X
Mexico	Abstain	-	-	-				Dates before 1900
New Zealand	No		X			X	X	Rename elements, vague
Norway	No			X				Split out DrawingML. Split out OPC
Peru	Abstain	-	-	-				Dates before 1900
Philippines	No			X				Dates before 1900
Poland	Yes			(X)
Portugal	Yes			(X)	X	X	X
Singapore	Yes			(X)
South Africa	No	X					X	Rewrite based on ODF. Make OPC a separate standard. Remove DrawingML and MathML
Switzerland	Yes			(X)				Dates before 1900
Thailand	No	X						Time for review
Tunisia	Yes			(X)	X
Turkey	Yes			(X)
US	Yes			(X)	X			X remove VML, Drawing ML, OPC, compatibility, dates before 1900
Uruguay	Yes			(X)		X		(replace VML with DrawingML, adopt MathML)
Venezuela	Yes			(X)		X

I have a confession to make. I’ve never had a formal class in C++ (though I’ve written quite a few). At no point did I ever get a professor spend several days trying to make me understand the significance of *,**,*void, &, ., -> or all those other rather strange glyphs that make reading C++ much like trying to understand the Chicago Manual of Style with 95% of the words removed.

The other day, as I was reviewing my Stroustrup, it occurred to me that a whole lot of programmers out there, especially in the web space, as likely as not never sat through that C++ class either, and so I began a thought experiment - if your only experience to programming was web development, how exactly could you teach someone about C++ in those terms? Curiously enough, the more I dug into this conceit, the more I realized that this was actually a useful exercise in understanding some fairly deep notions about how we deal with the concept of reference in programming and on the web.

One possibility for the co-existence that hadn’t grabbed my attention until today has probably been obvious to everyone else: when converting from OOXML to ODF just embed OOXML-namespaced elements inside the ODF where there is no direct equivalent.

This allows good round-tripping, doesn’t require ODF to be extended with legacy Office-isms, allows developers who want to support more than the ODF base to do so, gives better fidelity for Office users, improves round-tripping and doesn’t require that competitors sit down in the same room. Furthermore, in the case of say DrawingML, the original can be preserved as well as converting it to SVG, so the chances for round-off errors and data corruption from incomplete converter implementations is lessened.

ODF already allows foreign namespace elements. I guess what ODF would need to support this well would be a mechanism to say “This kind of foreign element should be stripped out when its context changes, but round-tripped otherwise.”

The reverse is also true: where ODF supports something that OOXML does not, it can either use the customXML elements or a separate XML part.

That would be a nice use of XML namspaces, actually. Rather than harmonize into a single format, augment each other without defining new elements. I don’t know that this would be satisfactory in every case, though. The daVinci plugin, as I understand it, generated ODF where it could but resorted to nonsemantic markup (binary?) where there was elements it didn’t understand or ODF didn’t support; a better approach would be to use Office Open XML elements for that purpose.

(In a previous blog, I raised the option that a document can be ODF and OOXML at the same time. The idea here augments that considerably. But it has the same thing in common: that there are other ways of thinking about ODF and OOXML than just as arch-rivals. People think that that either ODF and Open XML will go away: I think both will be around for a while so the issue we have to face is how to manage them. Hat-tip to Patrick Durusau for the namespaces idea.)

Step One: Set up a new project on GoogleCode.

Step Two: Access http://code.google.com/p/<project_name>/source and locate the “reset the repository” link on the right hand side of the page.

Step Three: Click that same mentioned link.

Step Four: Locate and click the “Reset Repository” button.

Step Five: Smile, knowing you’re about to “stick it to the man” ;-)

Step Six: Using your own GoogleCode username in place of mine, the location of your projects repository on your local file system in place my projects file system location, and your newly created project on GoogleCode projects name in place of my projects name, run the following command from the machine in which your projects repository is located,

svnsync init --username xmlhacker file:///srv/svn/nuxleus https://nuxleus.googlecode.com/svn

Don’t have access to the machine your project SVN repository is hosted on? No problem. Just replace file:///srv/svn/nuxleus with the network accessible svn://, http:// or https:// equivalent of your projects SVN root.

Step Six: With that process now complete, run the following, doing the same replacements mentioned above where appropriate,

svnsync sync --username xmlhacker https://nuxleus.googlecode.com/svn

Step Seven: Smile even bigger knowing “the man has just been stuck” with acting as a mirror for your projects SVN repository.

Step Eight: Stay tuned for the next installment of HGC, “[Hacking GoogleCode:Part Two] Using GoogleCode as Your Projects Main SVN Repository Without Having To Give Up Your Beloved Trac Project Management Interface To Instead Be Forced Into Using The Man’s GoogleCode’s Broke A$$ Attempt at Implementing a Proper Bug Tracking and Feature Management System Much Like I Have w/ the nuXleus Project Repository Which Is Now Happily Hosted on GoogleCode While My Beloved Trac Project Management Interface Is Still Firmly In Place and In Sync With the Check In’s Made To The GoogleCode Repository” (or maybe a title that’s a slight bit shorter than this one. ;-)

Update: DO NOT CHECK IN A SINGLE NEW REVISION IN YOUR PROJECT’S PREVIOUS REPOSITORY IF YOU PLAN TO USE GOOGLECODE AS YOUR PRIMARY SVN REPOSITORY.

Instead, either check out a new working copy from GoogleCode or use svn switch --relocate https://projectname.googlecode.com/svn from within your existing checked out working copy.

On the other hand, if you plan to use GoogleCode as a read only mirror (not really all that wise if you give read/write access to anyone other than yourself as, as far as I know, you can’t restrict check-ins to the GoogleCode repository past simply not adding any new project owners or developers),

DON’T CHECKOUT A SINGLE WORKING COPY FROM THE GOOGLECODE REPOSITORY USING https://. USE http:// ONLY OR FIND YOURSELF *REALLY* MAD WHEN YOU ACCIDENTALLY CHECK IN CHANGES TO YOUR “READ-ONLY” SVN REPOSITORY.

The early tallies I have of the number of comments from national bodies DIS 29500 is about 3,550: I expect there are an awful lot of duplications though. Is that a lot?

A question on this came up on XML-DEV this weekend.

Tim Bray said

The task of addressing all ten thousand or so ISO-member comments, even after removing dupes, and dealing with the callouts to unspecified product behavior, and so on, with no assurance that doing so would result in ISO blessing, seems just insanely expensive and difficult to me. If those guys take it on, they have my respect and sympathy.

Michael Kay responded

Actually, 10,000 comments on a 6,000 page spec doesn’t sound like a large number to me. If I had less than two comments per page on a book or spec I had submitted for technical review, I would be concerned that the review wasn’t thorough enough. Perhaps people were holding back because they don’t want to provide MS with a free QA service.

And Jim “ISO SQL” Melton added

Or perhaps most people were somewhat intimidated by the prospect of (thoroughly) reviewing a 6,000 page document. To put this in perspective for those who know SQL’s size and complexity, the sum of all nine parts of SQL is about 3950 pages. A ballot on SQL frequently receives several thousand comments, and we’ve been balloting versions of SQL for 20 years!

In fact, virtually every large spec I’ve ever had the “pleasure” to review leads to “thread-pulling”, in which every page yields at least “one more” bug, and following up on that one leads to more, and following up on those leads to still more, etc. I would personally be stunned if 30 dedicated, knowledgeable reviewers of a 6,000 page spec on its first public review were unable to find at least 3,000 unique significant problems and at least 40,000 minor and editorial problems. But that’s just me…

And here is a comment from my blog a few week’s ago:

A big standard will have a lot of changes. If my 30 page standard had 10 changes in its final stages of national review, then DIS 29500 will have about 1000 changes at the same rate (assuming it has 3000 normative pages, which is probably too much). That is just the slog in getting a standard out the door, tedious work not a cause of panic.

So my bold prediction is that the extreme anti-OOXML squad will alternate incoherently between “Its too many! We have to draw the line somewhere!” and “Its not enough! It is beyond the powers of mankind to read this thing!” while MS PR will alternate reactively “Its wonderful and thorough! Long live openness” and “We can do it in our sleep!” And the ISO process will continue calmly on, disappointing the bullies and the racists and the cartel-izers and the sour-grapers and the parrots, and deliver a good initial version of the standard. I think many reasonable people who had reasonable concerns about DIS29500 will see that the process actually has allowed their concerns to be addressed, and will see through the hysteria for what it is.

Update: To ensure proper context is propagated, as per Douglas Crockford’s follow-up comment below,

The context of my statement was Ajax data transfer. In that specific context, XML is in fact being replaced with JSON. I didn’t say anything about doing dishes.

Which, I believe, is an absolutely fair statement to make. In fact, if you were to run a couple of quick queries on the two pages this article spans you could determine quite easily that yes, in fact, this article had a heavy tendency to use the word ‘AJAX’,

Page1//html:p[contains(.,’AJAX’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_1.html//html:html/html:body//html:p[contains(.,’AJAX’)]

Page2//html:p[contains(.,’AJAX’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_2.html//html:html/html:body//html:p[contains(.,’AJAX’)]

What about dishes?

Page1//html:p[contains(.,’dishes’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_1.html//html:html/html:body//html:p[contains(.,’dishes’)]

Page2//html:p[contains(.,’dishes’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_2.html//html:html/html:body//html:p[contains(.,’dishes’)]

… Well, once again this statement can easily be determined to evaluate to true. Thanks for setting things straight, Douglas!

On a related note, isn’t it cool how you can combine something as ubiquitous as a URI path segment with something as ubiquitous as HTML turning the entire *live web* into an XPath query-able dynamic database as a result?

Anyone ever tried to do that same mapping with JSON?

Just wondering… ;-)

Enjoy your XML and JSON enhanced WebDevWeekends, everyone! :D

Update: I should quickly point out that my comment below regarding the comparison to Dave Winer had nothing to do with Crockford’s contributions to the development community — Douglas Crockford is a *HELLAVU* hacker and his contributions are both obvious and beautiful (as in Beautiful Code.) My statement was directly oriented towards his statement “Fortunately, XML has been replaced by JSON” which, if Dave Winer had invented JSON is exactly the kind of statement you would expect for him to make. Suggesting that XML has been replaced by JSON makes about as much sense as would suggesting that JSON has replaced data. While JSON is great as a data serialization format it doesn’t cook your dinner and clean your dishes. It’s a data container. A *NICE* data container, but a container none-the-less.

Anyway, just wanted to quickly clarify what I meant in my comparison below. Douglas Crockford doesn’t claim to have invented things he didn’t and then insist he be given credit regardless of the fact. And he most certainly knows how to write code like very few people on this planet are capable of. My apologies for making it seem I was suggesting otherwise.

[Original Post]

Web, AJAX slammed for deficiencies | InfoWorld | News | September 07, 2007 | By Paul Krill

XML is complicated and inefficient, he said. “Fortunately, XML has been replaced by JSON,” Crockford said. “This gives me some confidence that we can fix the standards in the Web. This is our first success at that.”

Yikes! And here I was thinking there would never again be another Dave Winer. ;-)

On Sept. 7, the US House of Representatives passed sweeping legislation to overhaul the US patent system by a vote of 220 to 175. The Patent Reform Act of 2007 (H.R. 1908), authored by Rep. Howard Berman, D-Calif., seeks to try to restore some balance to the patent system in the face of radical changes in information technology by introducing a number of changes increasingly sought by the software industry in particular:

I’m mostly happy about how Living in Dryden has turned out, and every now and then I try to encourage other folks to do something similar. Judging by the growing list of Dryden weblogs, I’d say Dryden is doing pretty well in building a community of people writing on a regular basis about things that matter to them.

A couple of months ago I did an interview with fellow technologist Jon Udell. He wrote up some of the interview (though I don’t think those are really ‘laws’), and the full interview is now available.

I’m also hoping to lead a panel on Creating Local Life on the Global Web at the SXSW Interactive conference next March. Talking about Dryden, New York in the middle of Texas may seem a bit strange, especially at a web development conference attached to film and music shows, but there’s a lot to do there.

When the Internet and the Web first appeared, they seemed like great ways to reach large numbers of people who weren’t already connected to each other. People who lived in California could talk to people in Germany, Bangaladesh, South Africa, and New Hampshire, about common interests they couldn’t have easily shared before. In the past few years, though, it seems that we’re learning about how these technologies can help us communicate on a much smaller scale, helping us look beyond the walls and property lines of our homes to connect with our neighbors.

There’s a lot to discuss here, and it’s not just about places like Dryden. Some ‘local’ communities are local once a year, at a conference or event, while many have members coming and going. Online communications let people who have left the community stay in touch with what’s happening, and even build new connections while they’re away.

If you’re interested in seeing this at SXSW, visit the panel-picker and vote for (or against) the proposal I’ve put in. (The Panel Picker is open until September 21st.)

As seen earlier today on XSL-List (this relates directly to yesterdays post: Opera 9.5 and XSLT document() Function),

Note that it’s entirely conformant (and sometimes even useful) for an
implementation of document() to reject every URI you throw at it as “not
recognized” or “inaccessible”. It’s not conformant, however, to fail to
provide the function.

Interoperability and marketability, of course, demand rather more than mere
conformance.

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

In the first few days of September, just as kids were beginning to head back to school, something rather remarkable happened: Microsoft lost its hegemony. In a vote by the various members of the ISO standards committee, managing only to come up 53% of the votes it needed to fast track the Office Open XML format for consideration as an ISO standard.

Now, Microsoft and its partisans will, most likely spin this as a temporary defeat, pointing to the number of No with comments votes that indicate that it may be possible, with some extensive work, to make OOXML workable in the near term future if some rough edges are smoothed out. In the end of the day Microsoft will have won, and those countries that were too narrow-minded focused on insuring that the standard that emerged was close to being workable with efforts will in the end change their minds, once the spec is cleaned up (and perhaps a few more people were added to the appropriate committees with positions financed by Microsoft money) that surely the OOXML standard will in fact become the de facto one very soon now.

We will (re)create it.

Please see this movie and then begin to think about what your creation(s) will be.

Thanks!

Update: via a suggestion from olli, I’ve added a post to the Opera forums which contains a poll asking whether or not Opera should provide support for the document() function in the next release of Opera, code named Kestrel. I would encourage anyone and everyone with interest to add their vote to the poll.

http://my.opera.com/community/forums/topic.dml?id=203214&t=1188904973&page=1

Thanks in advance!

[ Original Post ]
via a recent post I made to XSL-List,

via http://snapshot.opera.com/mac/m950a1.html (as well as all of the other platform changelogs),

Fixed numerous inconsistencies and specification violations in the SVG, DOM, WML, Web Forms 2.0, XPath, and XSLT implementations

“XSLT document() function will no longer cause an XSLT processing error if it is not called”

Okay, so I’m not sure that sentence makes any sense, so I’ve dug a little deeper.

@ irc://irc.opera.com/weekly

—
04:34 xmlhacker Hey All: Firstly, congratulations on getting Kestrel alpha out the door! Secondly, as part of the changelogs “XSLT document() function will no longer cause an XSLT processing error if it is not called” which, technically speaking I suppose, is true. If you don’t use document() function it won’t throw an error. However if you do, it still does. I’m running on Mac/Tiger > Simple oversight for an early alpha release?

04:40 olli xmlhacker: i asked one of da geeks here and he said: I believe it doesn’t throw an error when it’s not used. IT does throw an error when invoked
04:41 olli this means that if you test first if it’s supported and then use it if that’s true it no longer causes an error where it previously did

04:43 xmlhacker olli: got it. Thanks for the insight! So can someone @Opera clarify one way or another if document() function support will make it into Kestrel?

04:45 olli xmlhacker: maybe
—

And there ya have it folks. Of course there are those who will write off Opera as being a completely useless browser for client-side XSLT processing. But anyone who knows me knows one very important “quality”: I don’t give up.

I’ll report back once the battle has been won. (let’s hope that report comes sometime before the end of this decade ;-)
—

And just to add a bit more to this: Come on Opera! Are you a W3C web standards company or not? It’s not like you’re being asked to implement a deep down architectural change like XPath 2.0. This is an HTTP GET! That’s it! You’re a web browser company, you should be able to figure out how to do one of those, shouldn’t you?

Or is making a half a$$ed attempt at supporting web standards you may or may not have any interest in something we should just come to expect from this point forward?

Every so often, you come across a book that not only informs, but challenges your perceptions, leaving you seeing things in a way that you would not have before you started reading. I have a fair number of science fiction books that I’ve read over the years that left me in the major paradigm shift state after reading it (usually at about three in the morning), but its been rare in recent years that I’ve found a tech book that has done so. However, the book RESTful Web Services by Leonard Richardson and Sam Ruby (O’Reilly press, 2007) managed to do just that.

Rarely do I review XML design without seeing something like:

<spam>
<link>http://example.com</link>
</spam>

Putting URLs in element content seems to come naturally to people, regardless of the age-old convention from HTML:

<p>
<a href="http://example.com"/>
</p>

I’ve always disliked this, as I prefer to have URLs and IDs in attributes. I used to think URLs in content was a manifestation of database-refugee XML, but I see it a lot even in carefully-crafted formats.

As seen at the top of a Yahoo!/B-Side co-branded shopping cart check-out screen,

NOTE: Our shopping cart requires you to enter your shipping address when you place an order. Yes, you have to do this even if you are only purchasing a download. Yes, that seems a bit, well, stupid. Hopefully, you can forgive us this minor inconvenience. Just enter your billing address for your shipping address, and we can all put this behind us and move on. - The management.