Mozilla firefox and XPath namespace axis

C. M. Sperberg-McQueen shared with us, that Mozilla Firefox browser doesn't implement the XPath namespace axis (ref, http://cmsmcq.com/mib/?p=757). CMSMcQ has encouraged us to cast a vote on Mozilla forum, to push Firefox team, to implement XPath namespace axis. I agree with CMSMcQ, and also find that XPath namespace axis is quite a critical functionality for XPath data model. This is certainly true for XPath 1.0, where namespace axis is very critical (and Mozilla, implements XPath 1.0). In XPath 2.0, namespace axis is deprecated but namespace nodes still is a core part of, XPath 2.0 data model as well.

I have already casted my vote for this with my support at, https://bugzilla.mozilla.org/show_bug.cgi?id=94270.

Other's might follow, please.

Martin Fowler: UML Distilled, 3rd Edition

I have been reading Martin Fowler's book, "UML Distilled, 3rd Edition" since last few months (my book reading has been very slow, keeping in mind the time I spend on web these days, to do most of my learnings).

This is a great UML book (and has only, 175 pages but very good), and I recommend it to anybody wanting to know about UML (Unified Modeling Language).

How XPath compare values in prediates

A user asked question similar to following, on IBM developerWorks XQuery and XPath forum:

What does A = B and A != B mean in XPath expressions?

Michael Kay provided a very nice explanation to this:
The operators "=" and "!=" in XPath use "implicit existential quantification". So A=B is shorthand for "some $a in A, $b in B satisfies $a eq $b" (the longhand form is legal in XPath 2.0), while A!=B is shorthand for "some $a in A, $b in B satisfies $a ne $b".

So, not(A=B) is true if there is no pair of items from A and B that are equal, while (A!=B) is true if there is a pair of values that are not equal. In practice, you nearly always want not(A=B).

OO multiple inheritance, and Java

I have been thinking again, about multiple inheritance and why Java doesn't support it. I wrote a bit about this topic, some time ago.

There are so, so many resources on web about this, and it's actually very easy to find the answer to this, via a simple web search. Here is an article from where I started to know an answer to this, http://www.javaworld.com/javaqa/2002-07/02-qa-0719-multinheritance.html, which pointed me to this white paper by James Gosling and Henry McGilton. Really, I did not read this white paper by Java creators earlier (it never came across my eyes :)), in spite being familiar and working with Java since long time. Sometimes, we find gems on web in an unexpected ways (I mean, this paper is a gem for me :)). I'll try to read this paper (hopefully fully, and being able to understand it) over the next few days.

And here is a link in this white paper, which explains why Java doesn't support multiple inheritance. The following white paper link is also interesting, which gives a complete overview of C and C++ features, that were omitted in Java language (Java has been influenced from C and C++).

My personal opinion is, that if we must need to use multiple inheritance, we should just try to write programs in C++. On the contrary, my experience in using Java for about a decade, convinces me, that Java is suitable to solve almost any business application problem, and absence of multiple inheritance in Java, is not an hindrance to design good programming abstractions for problem domain. The advantages like Java's byte code portability and web friendliness far outweigh, any disadvantages caused by absence of multiple inheritance. On numerous occasions, I have created Java byte code on Windows, and used it without modification on Unix based systems (and vice versa). This is something which is built into the Java language, and it is cool!

Xerces-J: XML Schema 1.1 Conditional Type Alternatives (CTA), enhancements

Apache Xerces-J team has made enhancements, to the way XML Schema 1.1, Conditional Type Alternatives (CTA) are evaluated.

Following are summary of the recent XML Schema 1.1 CTA enhancements, being done in Xerces-J:

1) The XML Schema 1.1 spec, allows the implementations to use a smaller XPath 2.0 subset for CTA, and can also provide the full XPath 2.0 language, for CTA evaluations.

Xerces-J had the smaller XPath 2.0 susbset already implemented, for CTA since quite some time (which was contributed by Hiranya Jayathilaka), and that was the only XPath 2.0 support which, Xerces-J CTA implementation had earlier. Xerces-J team recently added full XPath 2.0 support as well, for XML Schema 1.1 CTA, using the PsychoPath XPath 2.0 engine (which is used, by Xerces-J assertions facility as well).

If the user, writes XPath 2.0 expressions adhering to the XPath 2.0 subset for CTA, then the native XPath 2.0 implementation in Xerces-J shall process those XPath expressions. But if the XPath expression parsing fails by the native Xerces-J XPath 2.0 processor, Xerces-J falls back to the PsychoPath processor for XPath evaluation, allowing users to use the full XPath 2.0 language, for CTA.

2) Some time ago, Xerces-J implemented the XSD 1.1 data type, xs:error as well, which is useful in XML Schema 1.1 CTA.

It's been quite a pleasure, working on some of these patches.

Xerces-J: XML Schema 1.1 assertions enhancements

The XML Schema 1.1 language, defines an assertions facility (xs:assert and xs:assertion), which constrain the XML Schema simple and complex types.

Apache Xerces-J implements XML Schema 1.1 assertions. As described in the XSD 1.1 spec, assertions typically have following XML representation:

  <assert
    id = ID
    test = an XPath expression
    xpathDefaultNamespace = (anyURI | (##defaultNamespace | ##targetNamespace | ##local)) 
{any attributes with non-schema namespace . . .}>
    Content: (annotation?)
 </assert>

For XML Schema simple type facets, the assertions are named, xs:assertion (as opposed to the xs:assert instruction for complex types) and rest of assertion contents are same.

Some background about XML Schema 1.1 assertions, and it's implementation in Xerces-J, could be referred at following blog post, which I wrote some time ago.

During the last week, we enhanced Xerces-J assertions to support the assertions attribute, 'xpathDefaultNamespace'. I did contribute this patch to Xerces-J, and it's now available on Xerces-J SVN repository.

The following XML Schema 1.1, specification description, describes how an assertions attribute 'xpathDefaultNamespace' works (please see the section, "XML Mapping Summary for XPath Expression Property Record {default namespace}").

Here's a simple example, about how 'xpathDefaultNamespace' functions in XML Schema 1.1 assertions:

XML document [1]:

  <X xmlns="http://xyz">
    <message>hello</message>
  </X>

XSD 1.1 document [2]:

  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
             targetNamespace="http://xyz"
             elementFormDefault="qualified">

     <xs:element name="X">
       <xs:complexType>
          <xs:sequence>
             <xs:element name="message" type="xs:string" />
          </xs:sequence>
          <xs:assert test="message = 'hello'" xpathDefaultNamespace="##targetNamespace" />
       </xs:complexType>
     </xs:element>

  </xs:schema>

In the XML document [1] above, since element "message" belongs to the namespace, "http://xyz" (by virtue of the default namespace declaration, xmlns="http://xyz" on element "X"), therefore the XPath (2.0) expression message = 'hello', on xs:assert instruction would return a boolean value "true", only if an element reference "message" in the XPath expression belongs to the namespace, "http://xyz". This namespace information needs to be provided to the XPath engine, via the 'xpathDefaultNamespace' attribute, on xs:assert instruction. If for the above XML instance document [1], 'xpathDefaultNamespace' attribute is not provided on the xs:assert instruction, then the XPath expression, message = 'hello' would return false (as then, the element "message" would be considered in no/null namespace, by the XPath engine), and the element instance at runtime, would become invalid according to such a XSD 1.1 Schema.

Allowing the 'xpathDefaultNamespace' attribute to be working on XML Schema 1.1 assertions, further increases the usefulness of XML Schema 'assertions' instruction, because now the XPath expressions, on assertions can be XML namespace aware.

The implementation of 'xpathDefaultNamespace' attribute on assertions, required enhancing PsychoPath XPath 2.0 engine as well. The updated PsychoPath library, JAR has been copied to Xerces-J SVN repository as well.

Xerces-J: XML Schema 1.1 inheritable attributes and CTA

I just had my XML Schema 1.1 inheritable attributes patch, and it's integration with XML Schema 1.1 Conditional Type Assignment (CTA) facility, committed to Xerces-J XML Schema 1.1 SVN dev stream. I had earlier written about this, on this blog.

Credits for Xerces-J inheritable attributes work, should also go to Khaled Noaman (a fellow Xerces-J committer), who reviewed my patch and suggested many improvements. The Xerces-J inheritable attributes work, adds to an earlier work for XML Schema 1.1 Conditional Type Assignment (CTA), by Hiranya Jayathilaka (also a fellow Xerces-J committer).