I will begin releasing updates to some of the MLZ legal styles shortly based on the more powerful syntax. The style updates will only work with the latest version of MLZ, so updating MLZ would be a good move at this point.

More soon!

Frank Bennett

Changes in this release include the following:

• Repair of a long-standing but largely invisible bug in item creators. When dragging to a group, items with language variants on a creator field set (or reused) a copy of the creator associated with My Library, rather than the target group. This anomaly did not have immediate side effects, but it was not correct, and all such entries will be fixed by the upgrade.
• Adoption of all recent changes to Zotero 4.0, including a fix for a sync issue affecting some attachment items created with earlier versions of Zotero.
• Simplification of MLZ schema upgrade logic to allow orderly management of MLZ and Zotero schema upgrades going forward. This one has no visible effect when using the application, but it is definitely A Good Thing.

Several users of the older version of MLZ have voiced reservations about Zotero-incompatible changes to the MLZ database made earlier this year. There is a good reason for the changes, but I have been listening, and at some point (not immediately, but perhaps by late summer) I will look into providing a reverse-conversion tool to restore an MLZ database to Zotero compatibility. This can be done without data loss, so there is no good reason (apart from time constraints) not to make it possible.

MLZ fixes

• A bug in MLZ duplicates detection was returning a huge number of false positive (fixed)
• Adjustments to CSL field mappings in MLZ
• The version field on the document item type triggered an error in MLZ sync (fixed)
• RTF Scan was producing incorrect bibliographies in AGM SIG-CHI and some other styles (fixed)
• New creators were showing “null” as the name in MLZ (fixed)
• MLZ list of CSL locales as incomplete, did not show all locales, and was non-functional (fixed)
• Abbreviations were being proposed for book titles in chapter type entries (fixed in MLZ and Abbreviation Filter)

CSL processor fixes

• Coding changes to address the abbreviation issue mentioned above
• Provide a mapping to human-readable CSL locale names
• Add some words to the title-case capitalisation skip-list
• Processor was not properly defaulting to by-cite disambiguation (fixed)
• The page variable was not recognised in is-numeric tests (fixed)
• Test of title-short field was failing (fixed)
• Complete rewrite of conditional evaluation code (no change in behaviour)
• Implement incremental application of disambiguate=”true”
• Fix a bug in the new rebuildProcessorState() function
• The first character of terms was being capitalised in in-text citations (fixed)
• Delimiters were lost on adjacent number nodes (fixed)

There are some significant items in these lists: many thanks to users who took the time to report. It is heartening that the pace of fixes in MLZ and the processor is slowing. We’ll see what turns up when the upcoming MLZ book is released, and our population of MLZ users grows a bit more.

Frank Bennett

As the volume of jurisdiction specifiers can be expected to grow considerably, I’ve implemented a new interface that can cope with the load. Jurisdictions are now selected via a search-as-you-type interface, borrowing code that Zotero uses for tag and creator entry. The data behind the interface is stored in SQL and fully indexed, so the volume of data should have no significant impact on usability going forward.

In the course of making the changes, I changed the structure of the JSON list of jurisdictions that I posted abut back in July. The refactored object has a cleaner nested structure, and would lend itself to expression in XML. If that were done, the list could easily be remangled with XSLT to provide a human-readable quick-reference list of codes on the Web. GitHub Pages provides nice support for that, which Aurimas Vinckevicius has used to publish field assignment descriptions for Zotero (repo). It works well and it’s flexible — I’ve adapted his code to do the same for MLZ (repo).

I don’t have an immediate need for a pretty-printed jurisdiction/URN:LEX listing myself, but it could be done with a small amount of work. If someone with XSLT skills and a stake in promoting clean metadata for legal materials would like to take on the task, I will be happy to offer write access to the jurisdictions repo.

2013.02.05
FB

As described in the earlier posts, this version offers a cleaner item panel, and will sync multilingual variants added to MLZ records. The awkward right-click widget in the “Extra” field has been removed, as it is no longer needed. This latest version will be documented in the MLZ book, which I hope to bring out via Amazon CreateSpace within the next month.

The new client contains migration code that should convert existing MLZ records, and update their timestamps so that they will be pushed to the Zotero server on the next sync of the client. The new client is database-incompatible with official Zotero, but both MLZ and official Zotero can be synced to the same library data, in the event that reverse-migration is required.

This is a major migration, and it should be tested before release, by people other than myself. If you are a current MLZ user, and familiar with the system (i.e. you know where your zotero.sqlite database is located and can make a copy manually before upgrading), please get in touch via the CitationStylist contact page. I’ve tried to be careful about the changes, but it would be better to catch any glitches before the client is thrown open to the world at large. Testing of the upgrade process is to only way to be confident that all is working well.

Frank

Documenting your software can be a humbling experience. Although MLZ was feature complete and stable and all those good things, two sections of the book bothered me. In the time since the manuscript was “finished”, it has become clear that they bother others as well; and as we slid into the holidays, I decided to do something about both.

One quibble was with the menu hacked into the Extra field. Several people picking up MLZ in our faculty and elsewhere have been tripped up over a missing jurisdiction value on legal item types. It is crucial to include jurisdiction information on any primary legal reference record, and the awkwardness of the interface for entering it was clearly going to be a problem. This was just the tip of the iceberg, actually: the MLZ styles rely on an assortment of fields that are not available in official Zotero, some of them quite nearly as important as jurisdiction itself.

The second issue was the lack of multilingual sync. A multilingual reference manager really comes into its own when records can be smoothly shared across national boundaries. Shared records with rich metadata lower the barriers to collaboration. This is where the real value is. Nonetheless I had steered clear of implementing multilingual sync, partly to keep my life simple, and partly out of a concern for database-level compatibility with official Zotero.

A third issue crept into the mix as I was fretting over the two problems above. Several users have been confused by the differing citation results produced by official Zotero and Multilingual Zotero when using the same CSL style. I realized that this was actually a side-effect of scrupulously maintaining database-level compatibility with the official client: either tool can be used against the same database, and many users seemed to be doing just that, because Standalone is cool and there is no Standalone version of MLZ (yet). The resulting confusion promised to make debugging of styles more difficult, and reflect badly on CSL and Zotero to boot.

So I laid a plan to address these niggles, which is now about 80% complete — hence this note. The changes are much simpler to explain than the forces that drove me to produce them. Here’s a short list:

• The item panels for the legal types will be cleaned up, and several essential fields will be added. A new Jurisdiction field will become available, which always carries a value and is accessible only via a controlled list. The default will be configurable at two levels: a temporary default for cross-border and international work; and a persistent fallback value set initially to the US jurisdiction. The funky menu on the Extra field will go away.
• Multilingual sync will work, without any special setup. Items with multilingual variant and non-Zotero fields in them will carry that data in the Extra field for sync purposes only. On the client side, this will be completely transparent; but you will notice the data as computerspeak gibberish prefixed to the Extra field in the online version of your libraries and groups. It will likewise be visible in-the-raw in any official Zotero client that syncs the data. You can (and should) just leave it there.
• For better compatibility between the MLZ legal styles and the styles in the official CSL repository, I will be reversing an early decision to map Date Decided and other primary date fields of legal item types to the original-date field. This seemed right semantically, but it has caused no end of frustration, even among the patient community of early adopters. We will be reverting the “primary” date to issued everywhere, and a new publication-date field will be introduced to cover cases (pun intended) in which the decision date and the publication date differ.
• The database upgrade needed to support these changes will break compatibility with official Zotero at the database level. It will still be possible to sync MLZ data to an official Zotero client; the only constraint is that the two systems be set up to use separate databases. That requirement of a conscious user decision will reduce the threat of confusion that had been brewing.

These are substantial changes, and there will be an impact on user data. Apart from the loss of database-level compatibility with official Zotero, some or all data formerly stored in the Extra field with the old menu hack may need to be reentered manually. I am not yet sure how aggressive I should be about supporting automatic migration. If this is a serious issue for you (and if you have read this far!) please let me know.

That’s all the news for now. Back to work, more soon when I have something to show …

Frank

Here is a capsule run-down …

General interest

• Order-of-magnitude speed improvement for large documents (i.e. those with 600+ citations). Thanks for this are due in the first instance to Rudolf Amman for reporting the fault. Simon Kornblith at Zotero is behind enabling revisons to the LibreOffice plugin, for which we should all be grateful. Rudolf deserves special credit for patiently testing early iterations of my own code until the revisions finally came right.
• Reconfirmed style test suite. Ad hoc style adjustments and changes to input conventions during past months produced some errors in the style suite. These have now been fixed, and the tests refreshed. We now have a sound foundation for moving forward.

Multilingual interest

• Enhancements to multilingual citation control. The affixes to supplementary multilingual fields in citations can now be controlled via Preferences and Document Preferences. Thanks for this go to Didier Davin, who reported on the conventions of cross-language citation in France (which the old layout was unable to handle). The user community in France has been particularly helpful in bringing multilingual support along.
• Multilingual document breakage fixed. Working with Didier and students here at Nagoya University on the multilingual enhancement, I discovered to my embarrassment that multilingual parameters were not being retrieved out of saved documents — because the necessary code had never been written. This is now fixed.
• Right-to-left editing. This was not enabled for item fields, resulting in broken content for fields consisting of a mixture of RTL and LTR characters in an RTL language. The interface will now switch correctly according to the BCP 47 (RFC 5646) language code entered in the Language field. Many thanks to Zotero user seadeer for reporting this fault, and for testing the code iterations that fixed things up.
• Multilingual creator move-up/move-down fixed. As I discovered when working with data for our faculty website, creators with their supplementary variants were not always treated properly as a unit when using move-up/move-down from the creator label left-click menu. This has been fixed.

Legal interest

• Jurisdiction input helper. Legal styles in MLZ rely on URN:LEX codes for jurisdictions and international organizations. This works fine once the data has been entered correctly, but there is many a slip ‘twixt cup and lip, and looking up these codes in a table is an awkwardness that we are here to avoid. A right-click over the Extra field will now open a context menu of the nations of the world, and selected international institutions, with sub-menus for federal jurisdictions. The jurisdiction lists are a first draft: the data is housed on GitHub, and I am very much open to revision proposals. This was prompted in large part by recent exchanges with user Isis on the Zotero forums, where the importance of better UI support for manual data entry became clear.
• Abbreviation lists. The minimal abbreviation lists used for testing are now beginning to fill out. Many thanks to Julia Caldwell for getting the ball rolling on this front through her excellent work on the New Zealand Law style and its companion abbreviation list.
• Parallel articles. As parallel support now appears to be working reliably for statutes and case reports, I have extended the behaviour to cover serialised journal articles. This does not work for all styles, but those for which it fails cannot be smoothly formatted as collapsed parallels in any case. All in all, it looks happy so far.

As this summary shows, user feedback continues to be the driving force behind quality improvement. My thanks to everyone for their patience, care, and generous optimism. With friends like these, MLZ can look forward to a bright future.

Frank Bennett, in Nagoya

The urn:lex scheme is used in MLZ for the limited purpose of identifying jurisdictional scope: it is not a full document identifier, and does not carry information on the issuing institution itself. Even within this limited scope, the MLZ scheme diverges from the examples provided by the Cornell LII Lexcraft pages, in that the “federal” level is expressed as a geographic scope (set off by a semicolon), rather than as a distinct category of jurisdiction (appended by a period).

This difference in treatment is due to pedestrian parsing concerns, rather than any ontological view of the position of the US Federal layer of government. The urn:lex scheme allows the use of domain names to specify international organizations, which (as domain names) are delimited by periods. In parsing, the split required to obtain “us” as the top-level jurisdiction of “us.federal” would also yield “un” as the top-level jurisdiction of (say) “un.org”. While this does not appear to cause any immediate conflicts, such a split does lose information from the domain name, and given the international scope of the MLZ project, there is a potential for namespace overlap down the road. Accordingly, a semi-colon delimiter is used to distinguish Federal from state jurisdiction at the top level.

Examples

Top-level Federal (Supreme Court, Congress, national administrative bodies)
us

Federal District (single district within state)
us;federal;wy

Federal District (multiple districts within state)
us;federal;ca.northern.district

State
us;ny

A preliminary list of identifiers is available for review.

(Update 2012-07-15: Jurisdiction data based on this scheme is included in abbreviation lists now available for use with the Abbreviations Plugin and the Wisconsin Court Style.)

(Update 2012-08-01: Abbreviation lists for all styles are now available.)

Frank Bennett