HCMC Blogs

Received an updated XML file from Yuko for the Katakana project. Checked it for validity, and then uploaded it into the main project db, and also into the Katakana 2 port we have running currently on Greg's machine for testing the new eXist.

• Looked into the deadline date bug. Turned out it was caused by the actual dates on tasks being wrong (tasks for early months of next year had 2006 deadlines).
• In the process of fixing that, decided that deadlines should be displayed in a useful manner.
• Added code to put deadlines in brackets after post titles in the report.
• Added more code to check the date of deadlines, and for tasks with status Outstanding, where the deadline is passed, display dates in red.

David helped a lot with this; I discovered I'd been doing some risky things in PHP (associative arrays using integer index values), so we switched them to strings for the sake of stability. David also helped debug a stupid error of mine (= instead of ==).

All of the transcriptions are done, but commentary on text and image has not begun. TEI header not done...

Looks like the deadline_from and deadline_to settings aren't having the expected effect. Urgent to fix this.

Created a sample header: sample_header.xml and linked it from the markup documentation page. Updated the sitemap so that plain xml docs like this can be delivered, and tweaked the markup page, adding a link to the sample header. Tag documentation should now be complete, pending any elaboration of the markup by adoption of new tags.

The simplicity of the tag structure leads me to believe we could cut the size of the schema considerably, if we put our minds to it. However, it's a bit early in the project to be removing options we might end up wanting to use.

The network in the labs has always been a bit flaky. I think there are a variety of issues here, such as faulty cabling in the labs (think C16 and transfer speed being half the going rate) and perhaps ACL issues on the switch.

I've made a request at the Helpdesk to look in to our own VLAN with our own ACLs etc. but I'll also need to track down the other problems. Task coming in next.

I've acquired 6 or 7 17" CRT monitors from the UVic bookstore. There is no cost other than delivery (FacMan charge). They are apparently in good condition.

I've been working on documenting tagsets, and there are two new pages on the site:

• Markup Conventions
• Schemas

The first is the one most relevant/useful for Claire and France. If you print it, it should come out nice and clear (it has a special print stylesheet to remove the site graphics, headers, footers etc.), so you can keep it by you as a reference. It turns out the number of tags you're actually using is very small, and I think I've covered almost all of them.

I'm now working on a sample <teiHeader> with explanatory comments.

I sent the post below (third paragraph down) via email yesterday. I'm posting it here now. The first paragraph below is my comment to Martin's response. His original response is the second paragraph down.

I have no problem using the term "proposal" instead of "charter" on the online submission form, or eliminating the word altogether from the web site or the form. But I really don't want to make substantial changes to the process outlined on the web site (again, see http://web.uvic.ca/hcmc/researcher/planning.php). A project "overview" is not the same as a submitted proposal, because it involves our evaluation, approval, resource allocation, etc. If these items belong in the plan (especially for smaller projects), so be it, but they need to belong somewhere, agreed upon formally by all, to "hang on the wall" in the formal Documents category of the project blog. For larger projects, the "overview" proceeds to and is superceded by a plan. The overview is "what", the plan "how". I don't mean to cover old ground, but Stewart and I set up the process posted on the web site after some discussion and consultation, and I would prefer to stick to it.

Martin: Incidentally, the word "charter" has to go. It's meaningless in this context, and part of the problem with evaluating these documents is that nobody knows what they are. It's a proposal. Once it's accepted, it should be superceded by a plan. Everybody knows what they are and what they're for. You evaluate and accept or reject a proposal; you follow a plan. What do you do with a charter? Hang it on your wall?

Scott: As of the moment we have laid out a process for charter creation that involves consultation and write up by one of us (see http://web.uvic.ca/hcmc/researcher/planning.php). These are guidelines based on practices, and can be changed if we feel another method would be more effective.

My questions are:

• Do we want to change our practices around charter creation (allow folks to submit without consultation) or do we wish to address only the mechanism?
• We have agreed already that charters "precede" blogs, so where do we post charters initially?
• Charters require consultation and review, so how do we circulate criteria/charter effectively for comment and approval? (A blog seems the obvious place for this. Perhaps we create another blog called "Proposals"?)

I like the idea of an online submission form but realize quite clearly that any charter submitted by a researcher will need substantial revision after consultation with us. We could close the online form to internal use only, or just expect that substantial revision will be required regardless of who submits it originally.

Comments, questions and suggestions, please.

This task's deadline has been pushed into March because it's not worth doing until we have assessed whether we are to move to B2Evo 1.9.2. There's no point in doing a customization, then having to port it to a new system; best to undertake it on the new system if and when it's running.

In some blogs, we want outsider comments (e.g. the IMT blog, where users have posted bug reports). On others, we want to limit comments to logged-in users. This is not possible with B2Evo. There is a documented hack here showing how to limit all comments to logged-in users; in order to extend this to make it configurable per blog, we'd need to create a new boolean db field in the blogs table, add to the admin GUI a checkbox for turning it on and off, and extend the hack code to check for both login and/or this boolean before allowing a post. Not urgent, but very desirable.