My experiences at the Open Source Convention
I’ll be posting there regularly instead of here for OSCON updates. I’m already having a blast

.

Are you thirsty all the time?
Do you find a need to drink sixty-four ounces of water a day?
You may be suffering from SAS: Sodium Abundance Syndrome.
Ask your doctor about Placebo^TM.
Placebo is a non-dietary supplement designed to relieve the symptoms of SAS. It should not be taken in concert with alcohol or other medications.
Common side effects include starchiness, bankruptcy, decreased appetite, and water consumption

.
You should not take Placebo^TM if you are already taking other medications such as acetomenaphen.
Placebo^TM: Because taking a pill should make you feel better… until you get the bill.

Give it up. I turned on e-mail notification of all the comments to my blog last week

. When you place a link to advertise a product that has nothing to do with what I write about, I’m going to know and I’m going to delete it.
Have a nice day. 🙂

This is a bit of a rant session, so if you’re not interested in hearing someone complain, skip this entry.
(1) My internet connection @ home is down. So I’m stuck playing with Mozilla 1.7 RC1 and Nvu 0.2. Nor can I get recent source code from the trunk.
(2) The neighborhood I live in does not have DSL support yet.
(3) SBC won’t give me a friggin’ clue when the neighborhood I live in might have DSL.
(4) I don’t think I can afford cable broadband (at $7.50/hr, 32 hrs/wk, the budget is a bit tight)
(5) What about dial-up? Only the desperate would consider doing CVS updates via 56K modems… of course, I did consider it…
(6) … until I found out the computer I work with at home doesn’t have a 56K modem.
(7) Laptop computer? I’m actually saving up for one, and I probably can purchase one at the end of the year..

. bear in mind this comes from a projected surplus of $150.00/month, after the first three months (during which I’m really thinking about OSCON and Abacus).
(8) Of course, when I do have the money saved up for a laptop, it probably won’t be top-of-the-line, and I’ll still have to go to Kinko’s to get my CVS updates and recent software…
(9) My efforts to convince the local library to install Mozilla anything have gone completely unanswered. *sigh*
On another note: Firefox 0.9 is out, eh? I’m surprised to see both mozilla.org and mozillazine.org responding well today. I’d think the slashdot effect would make people cringe. (Thank goodness they didn’t release Mozilla 1.7 final at the same time…)

One of the questions I’ve not yet answered for my own purposes is how to handle multiple human languages for documents containing MathML. I’m beginning to think my initial approach was a bit naive.
Initially, I had planned on a parallel markup scheme:
<semantics encoding=”MathML-Content”>
<!– … –>
<annotation-xml xml:lang=”en-US” encoding=”MathML-Presentation”>
<!– … –>
</annotation-xml>
<annotation-xml xml:lang=”fr-FR” encoding=”MathML-Presentation”>
<!– ..

. –>
</annotation-xml>
<!– … –>
</semantics>
However, if the parent document itself is a multilanguage document, this may not work very efficiently.
For example, if the document follows the conventions the W3C currently suggests, then a CSS stylesheet which hides the user’s non-native languages:
*:not([xml|lang=”en-US”) {
display: none;
}
would lose that whole fragment if it were in a section of the document designated fr-FR.
The solutions to this are at the moment non-obvious. Certainly I haven’t figured out a universal solution. (I am proceeding on the assumption that the browser is receiving the document post-processing from the server, with multiple languages in the document itself.) For all I know, Mozilla may already hide content that’s not from the native user’s language. Again, this is bad if the entirety of the MathML expression resides in one fragment.
I may have a partial solution. Instead of parallel markup contained in a single MathML expression, I might be able to spread it out:
<html:div style=”display:none;”>
<semantics encoding=”MathML-Content”>
<!– … –>
</semantics>
</html:div>
<!– later –>
<html:div xml:lang=”en-US”>
<semantics encoding=”MathML-Presentation”>
<!– … –>
</semantics>
</html:div>
<!– later –>
<html:div xml:lang=”fr-FR”>
<semantics encoding=”MathML-Presentation”>
<!– … –>
</semantics>
</html:div>
I’m looking for additional ideas on making XML/HTML documents truly international… and possibly refinements of this idea.

http://feedhouse.mozillazine.org doesn’t like me…
Also, someone’s been spamming the blog replies again. I cleaned it up

. (I do value your comments, so I leave the replies feature on.)
(Thanks for the correction on the URL.)

I noted with some interest Daniel Glazman’s weblog entry about a contract to develop an XML editor possibly based on Mozilla code. I think it’s a great idea, and I have an idea which (at least to me) makes sense for it.
Every XML language is different. XHTML, MathML, SVG, RDF, XUL, XBL… the only thing they have in common is that they are XML languages. Mozilla Composer has a XUL interface for editing HTML

. I’m developing a XUL interface for editing MathML. Several people have attempted, with apparently limited acclaim, to develop XUL interfaces for editing XUL.
There’s a trend here: one XUL interface for editing one XML language.
I think this trend is a very good one. My approach of using a dialog to edit MathML may not work out all that well in a multi-language editor, but my point is we should probably separate the language-specific user interfaces (Table, Anchor, Link, Image, etc.) from the language-independent UI (New, Open, Save, Spell check, etc.). This would allow such a project to utterly shed the dependence on (X)HTML that we currently have.
I have big problems with the HTML bias in Composer. The HTML Tags view needs a face lift if it’s going to work in this new project. It uses images to place the yellow HTML tags before elements. That’s all well and good, when you have a limited set of tags to deal with. When you include a larger set of elements, it becomes a burden on the developer writing the language UI to come up with appropriate tags. (For Abacus, I’m not even going to bother; I’m going to have it add one image, probably in green, for math elements, and have it wipe out all descendant images for tags.)
I’ve already griped earlier about other weaknesses for Composer’s extensibility. I hope the Disruptive Innovations team takes me seriously…
(Though I suspect that until I release Abacus 0.1, no one in Mozilla development will take me seriously… and with good reason…)

A few days ago I wrongly claimed that Nvu and Mozilla Composer would wipe out a document’s native doctype. My tests aren’t showing that now, which means I was likely thinking more about the spaghetti-sauce-of-the-day than about actual coding at the time.
I wanted to make this apology public for that foul-up.
I found, in the Preferences for Nvu 0.2, an installer for extensions. This discovery makes me a very happy man; I don’t have to worry about command-line installation of Abacus anymore. (In theory.) I’d guess this is the extension manager ballyhooed about.
I’m thinking one extension that would make a “killer ext” for Mozilla would be a little PNG editor. People who develop templates for MathML editing probably would like to create icons for the menu items they’ll create. Of course, Mozilla wasn’t really intended to edit graphics, but one can dream…
I noticed, absently, that Nvu 0.2 doesn’t like XHTML. (Yes, I know, after what I said about doctypes, I hear a “here we go again” groan…) It likes HTML just fine. With a little tinkering, it will like HTML + MathML as well. But when I have a link tag:
<link href=’chrome://gre/res/mathml.css’ type=’text/css’ rel=’stylesheet’/>
Nvu will record that as:
<link href=’chrome://gre/res/mathml.css’ type=’text/css’ rel=’stylesheet’>
I can’t get mad at Nvu for doing that; it’s a perfectly natural cleanup for HTML, and Nvu has no way of knowing that I want XHTML. Same problem in Mozilla Composer; it’s not really a bug.
This makes me wonder: what am I supposed to do about it? Per the XHTML Media Types note of the W3C, XHTML 1.0-compatible content types should not be used for text/html documents. In Section 3.1, the document specifically points out XHTML + MathML as “NOT suitable” (their capitalization).
I thought I saw a doctype for HTML + MathML a long time ago… can’t find it in MathML 2.0 1st Ed. (I’m about to grab MathML 2.0 2e.)
In terms of Abacus progress: the assert() function is proving very helpful indeed in forcing me to do things right. I’m just about at the point where I can save templates, but I hit a snag first: every template I create needs a file to save the template to. I placed an assert to throw an exception when I reached that point in my code, and forgot about it.
When I ran the code after fixing a couple other bugs, I noted with some concern that nothing seemed to happen after I okayed a template… and then my JS Console provided a very stern reminder. As I can’t really do any more work on Abacus without fixing that bug, I think I’d better write some code to identify a file for a new template, or create one if necessary..

.
After that, it’s building a UI for template writers to make UI’s for their templates… that, fortunately, will be the last thing required for actually editing MathML templates, and I can finally get on to editing MathML with the templates. That should be easy in comparison.

It’s becoming painfully obvious to me that Mozilla Composer wasn’t really designed for extensibility along the lines of what I’m attempting with Abacus (namely, adding support for a secondary markup language).
For instance, Composer adds stylesheets based on the tab you’ve selected at the bottom. If you select the Tags tab, you get a special stylesheet with lots of yellow image boxes for your elements. So far, so good.
Except for how it applies the stylesheet..

.
I tried doing an XUL overlay for the stylesheet (EditorAllTags.css). That was unsuccessful. I figured out later that the stylesheet was applied through C++ code:
http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editor.js#1928
http://lxr.mozilla.org/seamonkey/source/editor/libeditor/html/nsHTMLEditor.cpp#3730
This stinks. It’d be much easier if we could just apply stylesheets from the Document Object Model, as DOM-2 Style suggests. I’m tinkering around with that idea (based on DOM-2 Events to tell me when to apply the sheet and when to kill it) to make the styling work properly.
It’d also make sense, from a undo/redo point of view, if the various settings used a single transaction manager, and created alternate “views” for the document being edited. The document itself would remain hidden from the user, though all manipulations the user carried out on a view of the document propagate down into the master doc through a transaction manager. I remember someone on the Composer team long, long ago saying this might be a possibility. (Until the Nvu source gets checked into Mozilla’s tree, it’ll be a little hard for me to check that…) Having that undo/redo done this way would make it easier/safer for external applications, like DOM Inspector, to become a part of Composer.
Finally, I cannot for the life of me figure out how in Composer a HTML 4.01 Transitional doctype gets in when the document I’m loading already has a doctype tag.

My kind of plug-in.