No PDFs?

No PDFs! is not the answer. The answer is to make data available in a variety of formats and explain the relationship between them. In such a world, PDF becomes one format amongst many. That is good.

The problem with a lot of the "just give us XML!" exhortations is that it is easy to over-simply the issues that arise with legal and regulartory materials.

In an XML L&R world, PDF has its place. So too does Microsoft Word, OpenOffice, TIFF, custom-schema XML, industry-standard-schema XML, JSON, RDFa etc.

The whole point of using XML "upstream" is to allow a multiplicity of transforms downstream. However, care needs to be taken when the documents are critical - like legislation...It is critical that the normative copy is made explicit. The ideal normative copy is one that can partake in author/edit cycles. However, the normative copy is (typically) the result of a printing process because paper is signed by empowered officers with an ink pen. On the way to paper, there are umpteen points of intervention in the typical paper printing workflow. Camera-ready or direct-to-plate workflows in print shops involve page imposition and all sorts of pre-flight work that can - and often do - render the upstream content suspect with respect to the final printed pages.

Legislative artifacts - especially bills - need very close attention to line/page numbers because of the time honored way in which legislative amendment cycles work. Most knee-jerk "structured" XML approaches fall flat on their faces as a result. With legislation, line/page numbers are not throw-away artifacts. They are as important as the words themselves...

None of the problems are insurmountable but they involve a lot of care and thought. Throwing out PDF isn't the solution. Simply plugging in a structured XML editor with a custom/industry schema won't work either. The solution involves combining structured XML technology with wordprocessor technology and DTP technology. The key is recognizing that a multiplicity of formats/techniques are required in order to serve the needs of the complete legislative workflow; and to be absolutely clear - every step of the way - what the normative copy of the digital text is.

DSLs, Ruby, Lisp...

I have posted an article on ITWorld called Ruby, DSLs and the free lunch that was not so free.

Yup, Python sure is slow

This web server clinches the argument. A mere 8 *thousand* requests a second. Pah. Humbug.

:-)

SGML and justifiable complexity

Rick Jelliffe is writing some interesting stuff these days on parsing : SGML, XML, HTML etc. Rick talks about GROVES and that triggered a flashback. Boy, those were the days! DSSSL, HyTime...I remember GROVES being extruded into Graphical Representation of Property values. Rick says GROVEs—Groupings Of Valid Elements. Tomayto. Tomato. Its very instructive to watch the recent RDF goings-on in the light of the GROVE stuff of old.

Anyway, Rick makes the important point that you cannot linearize SGML parsing because it has feedback. Amen to that. SGML has more feedback loops than a room full of amps and microphones - as anyone who has tried to write a true SGML parser will tell you.

For me, the big question is this: is that complexity justified? Given that SGML is, after all, an invented language, its degree of parsing computational complexity is in human hands. With invented languages, we make parsing problems that we then have to solve. Does the cost outweigh the benefit?

In the case of SGML, I believe the answer is no. Charles Goldfarb has a brilliant mind but it is the mind of a lawyer moreso than a computer scientist in my opinion.

Now I work with legal texts a lot in my day job. I have read Peter Suber's Paradox of Self Amendment and I'm pretty familiar with the difficulties of creating homomorphisms between concepts from logic and concepts from jurisprudence.

"That legal rules may be bad logic and good jurisprudence at the same time is yet to be established, of course, but I will at least allow myself to proceed as if that conclusion were not foreclosed a priori." -- The Paradox of Self Amendment

I am as fond of hermeneutic circles as the next language nerd person but I think we need to create Strange Loops with caution in computer science. We need to bring an awareness of the issues they create downstream from the intellectual delights involved in their creation.

Now insofar as markup languages are attempting to be expressive in a human language sense, we get pulled towards parsing complexity. Insofar as we are designing them for machine readabilty, we get pulled towards simple models in the Chomsky-esque taxonomies of language types.

It is the age old debate in disguise. Are markup languages a branch of linguistics or a branch of mathematics?

The answer of course is "yes" and there-in lies the heart of the problem.

Never extrapolate...

Note to self: Never extrapolate anything from an experimental observation population of size two.

Software application architecture versus software application design

A software variation on a theme by Antoine de Saint Exupéry:

"A software application architecture is finished when there is nothing left to take out. A software application design is finished when there is nothing left to add."

JSP (the real one) and XML

Sadly, another year has passed and my 100% record of not attending the Balisage conference is intact.

This year looks to have been particularly interesting with Michael Kay speaking not only on pipelines but on the fascinating overlaps between markup processing and an all-but-forgotten software design methodology known as JSP (Jackson Structured Programming).

At SGML '96, I gave a talk on the relationship between the JSP methodology and SGML processing. At the time, we were using the ideas in JSP extensively in an C++-based SGML processing toolkit we called IDM. Its great to see JSP get some air again as there is a lot of stuff in Michael Jackson's thinking that really resonates today. Not only the ideas in JSP but also the ideas in JSD (Jackson Structured Design).

I had the great good fortune to work for Dave Croydon of Fiamass when I left college. He introduced me to JSP in the context of building real-time financial trading systems in 8086 assembler! I didn't know it then but what I learned from Dave hugely influenced the approach I would end up taking to everything from programming to system architecture at Propylon.