Over the last couple of years I had ignored XProc as something to process my XML with. There were no special reasons for this neglect. But as we all know, there is only so much time and too many things to do, learn and discover. And we have to earn a living as well, don’t we?
But in the last half of 2013 I was asked by a client to create a complex XML conversion application. Alternative approaches (for me) would have been Cocoon (which seems rather out of fashion) or eXist+XQuery+XSLT (which did not fit the technical environment). So I decided to pick up XProc (on Calabash) and give it a try. (more…)
XQuery is the language for working with XML databases. It can also be used as a general purpose language for working with XML.
If you have functions in XQuery with side effects (e.g. updating a log) that return something you don’t want to use, you have a serious problem. This blog explores this and proposes some solutions. (more…)
XML databases are usually marketed as, well, just databases: Applications in which you can store vast amounts of data, combined with mechanisms to index and query the stuff. That sounds logical (given the name of the product category) but is IMHO only half (or even less) the story. After some deep immersion into eXist for several months (and some more shallow experiences with MarkLogic and 28msec), I do think this product category has a much wider application than its name of it implies (more…)
A few month ago I started my first serious programming project using XQuery (on eXist-db). Although the language is easy to master when you already know XPath, it has IMHO a few quirks. Here is, IMHO, the worst (more…)
Some tiny typing mistakes in your XSLT stylesheet can cause major headaches. Why? Because they go undetected by the standard static and dynamic error checking mechanisms. Something as simple as writing /Filename where it should be /FileName will only show up if your own test/debug efforts find it and will not be trapped by the XSLT engine. Unless… (more…)
Looking at the XML that is around, everybody seems to use different standards for element and attribute names. Some people write their elements in all uppercase, like <USERNAME>, some use UpperCamelCase, like <UserName>, or lowerCamelCase, like <userName>. Some standards, like XSLT, use all lowercase, like <xsl:value-of>. There is no uniformity, in contrast to, for instance, Java, where everybody more or less adheres to the same writing and coding rules.
So should we have a standard and what should it look like? Let’s explore. (more…)
In an XML document you can express the same semantics in syntactically very different ways. Which is a difficult way of saying: Watch out, XML documents may look different but can nonetheless mean the same! If you use the right tools to parse and interpret the XML that is not a problem. However, be aware for developers that do not…
This article explores the areas that cause most of the confusion in interpreting XML. (more…)
Once upon a time XML was born from SGML. And along with its birth came DTDs to define the document structure. Life was good. Everybody used to writing DTDs for SGML could keep doing so. And so they did…
But what happened? Newer and shinier methods for describing XML structures came along. W3C Schemas, Relax NG and others saw the light. Suddenly things that were impossible to do with DTDs became feasible: data typing, design modularization and many, many more. Wow! Suddenly you could really be strict about your document structure.
And so what happened in the ivory towers from which the gods send us their XML standards for us mere mortals to use? Where the standards accompanied by schemas in addition to the traditional DTDs? Yes, they were! Hurrah, a step forward. Now we can really and truly verify our documents.
But look closely. Are this schemas? Technically… yes. However they look an awful lot like DTDs. If I am not mistaken most of the DTDs are simply converted into schemas.