There was an annoucement recently from IBM (http://webspherecommunity.blogspot.com/2009/04/was-open-xml-feature-pack-beta.html), about availability of "WAS XML Feature Pack Open Beta" supporting XPath 2.0, XSLT 2.0 and XQuery 1.0. It was good to know this.
Therefore, users would be able to use XPath 2.0, XSLT 2.0 and XQuery 1.0 in a WAS environment, using IBM's own processors for these languages.
This is an early preview release, with more enhancements expecting to come later.
I'm looking forward to try these language processors myself.
Thursday, April 23, 2009
Tuesday, April 21, 2009
Xerces-J: XML Schema 1.1 assertions support
This post is related to my earlier blog post, http://mukulgandhi.blogspot.com/2008/07/assertions.html about the XML Schema 1.1 assertions implementation into Xerces-J.
Today, I reached an important milestone with all the development finished for assertions in Xerces-J, and submitted an Apache JIRA issue for review.
Here is a small example of what XML Schema 1.1 assertions means:
With this XML Schema 1.1 fragment, the user wants to have a validation constraint that, the price string should end with literal 'USD' and pub-date should be greater than the date 2007-12-31. This is a very simple example, but it does signify the usefulness of assertions syntax. We could have unlimited (0-n) numbers of xs:assert elements in a XSD schema type (which could be a simple type or a complex type. Though the assertions facet name in simple types is named xs:assertion). The value of 'test' attribute in assertions is an XPath 2.0 expression. All the assertions have to evaluate to boolean, "true" for an element to be locally valid.
There could be many other scenarios (and some of them quite complex, like for e.g., assertions present in a Schema type hierarchy) for writing assertions in XML Schema 1.1. It's difficult to specify all of them here. I'd ask the reader, to read the article [2] below, for learning about many of other, XML Schema 1.1 assertions scenarios.
With assertions in XML Schema 1.1 language, we could express much more involved XML validation constraints, that were almost impossible to specify in XML Schema 1.0. Using assertions, we can specify relationships between elements (like element names, contents etc), between elements and attributes, between attributes, and perhaps much more.
The assertions processing in XML Schema 1.1 works as follows:
When a XML Schema (1.1) processor encounters an element in the XML instance document, it must validate the element (if the user has requested validation) with it's associated type in the Schema (which could be a simple type or a complex type). The element's type declaration could be anonymous, or it could be a named type (which has a "name" attribute, and they are globally defined in the schema) declaration in the Schema. The XML Schema processor builds a XPath data model (XDM) tree rooted at this element (with Xerces, a XDM tree is built only if any assertions (which could be, 1-n in numbers) are associated with an element's type. If schema types of XML attributes have assertion facets, then these assertion facets work upon the attribute's value, and no XDM tree is constructed in this case). The XDM tree consists of the root element, it's attributes and all it's descendants. When an element validation is going on within Xerces, assertions evaluation also takes place as part of the validation process. Each assertion is evaluated on the XDM tree rooted at a given context element. Therefore, also any attempt by the assert XPath expression to access any node outside this element tree will not succeed.
We also have a wiki page for Xerces assertions implementation, http://wiki.apache.org/xerces/XML_Schema_1.1_Assertions. It describes a bit of implementation details of assertions in Xerces.
I'm happy to share that we expect Xerces-J to support the whole of assertions implementation in a near future release. And of course, Xerces would support lot of other XML Schema 1.1 features as well.
Following are few nice articles related to XML Schema 1.1, which are worth reading:
1. Overview of XML Schema 1.1 language
2. XML Schema 1.1 co-occurence constraints using XPath 2.0
Today, I reached an important milestone with all the development finished for assertions in Xerces-J, and submitted an Apache JIRA issue for review.
Here is a small example of what XML Schema 1.1 assertions means:
<xs:complexType name="book">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="author" type="xs:string" />
<xs:element name="price" type="xs:string" />
<xs:element name="publisher" type="xs:string" />
<xs:element name="pub-date" type="xs:date" />
</xs:sequence>
<xs:assert test="ends-with(price, 'USD')" />
<xs:assert test="pub-date > xs:date('2007-12-31')" />
</xs:complexType>
With this XML Schema 1.1 fragment, the user wants to have a validation constraint that, the price string should end with literal 'USD' and pub-date should be greater than the date 2007-12-31. This is a very simple example, but it does signify the usefulness of assertions syntax. We could have unlimited (0-n) numbers of xs:assert elements in a XSD schema type (which could be a simple type or a complex type. Though the assertions facet name in simple types is named xs:assertion). The value of 'test' attribute in assertions is an XPath 2.0 expression. All the assertions have to evaluate to boolean, "true" for an element to be locally valid.
There could be many other scenarios (and some of them quite complex, like for e.g., assertions present in a Schema type hierarchy) for writing assertions in XML Schema 1.1. It's difficult to specify all of them here. I'd ask the reader, to read the article [2] below, for learning about many of other, XML Schema 1.1 assertions scenarios.
With assertions in XML Schema 1.1 language, we could express much more involved XML validation constraints, that were almost impossible to specify in XML Schema 1.0. Using assertions, we can specify relationships between elements (like element names, contents etc), between elements and attributes, between attributes, and perhaps much more.
The assertions processing in XML Schema 1.1 works as follows:
When a XML Schema (1.1) processor encounters an element in the XML instance document, it must validate the element (if the user has requested validation) with it's associated type in the Schema (which could be a simple type or a complex type). The element's type declaration could be anonymous, or it could be a named type (which has a "name" attribute, and they are globally defined in the schema) declaration in the Schema. The XML Schema processor builds a XPath data model (XDM) tree rooted at this element (with Xerces, a XDM tree is built only if any assertions (which could be, 1-n in numbers) are associated with an element's type. If schema types of XML attributes have assertion facets, then these assertion facets work upon the attribute's value, and no XDM tree is constructed in this case). The XDM tree consists of the root element, it's attributes and all it's descendants. When an element validation is going on within Xerces, assertions evaluation also takes place as part of the validation process. Each assertion is evaluated on the XDM tree rooted at a given context element. Therefore, also any attempt by the assert XPath expression to access any node outside this element tree will not succeed.
We also have a wiki page for Xerces assertions implementation, http://wiki.apache.org/xerces/XML_Schema_1.1_Assertions. It describes a bit of implementation details of assertions in Xerces.
I'm happy to share that we expect Xerces-J to support the whole of assertions implementation in a near future release. And of course, Xerces would support lot of other XML Schema 1.1 features as well.
Following are few nice articles related to XML Schema 1.1, which are worth reading:
1. Overview of XML Schema 1.1 language
2. XML Schema 1.1 co-occurence constraints using XPath 2.0
Friday, March 20, 2009
Data modeling approaches
With reference to my earliest blog post on "Relational/XML hybrid database design",
http://mukulgandhi.blogspot.com/2009/01/relationalxml-hybrid-database-design.html,
I have some more thoughts on this topic.
I think, an information model of an enterprise should consider XML as a first class data storage mechanism, along side the relational mechanism.
When XML was not there, using relational storage (and some other forms of EIS data) was the only choice. Given the benefits of XML (some of which are mentioned in my previous blog post cited above), it should be considered equally important as the relational mechanism, for data persistence needs.
There should be a mixture of XML and relational data in the overall data model of an enterprise. This would bring best of the worlds of relational and XML storage, to the enterprise's data.
I have seen that, today XML is used a lot for various kinds of property/configuration files, and for sending messages. But I feel, that wherever it makes good business sense, the core business entities should be modeled as XML along side the relational models. With the current hybrid XML/Relational databases (like, DB2 with pureXML), we can have the relational and XML data in the same transactional context.
http://mukulgandhi.blogspot.com/2009/01/relationalxml-hybrid-database-design.html,
I have some more thoughts on this topic.
I think, an information model of an enterprise should consider XML as a first class data storage mechanism, along side the relational mechanism.
When XML was not there, using relational storage (and some other forms of EIS data) was the only choice. Given the benefits of XML (some of which are mentioned in my previous blog post cited above), it should be considered equally important as the relational mechanism, for data persistence needs.
There should be a mixture of XML and relational data in the overall data model of an enterprise. This would bring best of the worlds of relational and XML storage, to the enterprise's data.
I have seen that, today XML is used a lot for various kinds of property/configuration files, and for sending messages. But I feel, that wherever it makes good business sense, the core business entities should be modeled as XML along side the relational models. With the current hybrid XML/Relational databases (like, DB2 with pureXML), we can have the relational and XML data in the same transactional context.
Saturday, February 28, 2009
Ptarithmetic: logic in computer science
A post on comp.theory newsgroup referred to this paper, by Giorgi Japaridze. I read a bit of this paper, and believe the thoughts presented here are quite promising (at least, I found the goal of this study quite ambitious). I guess, people with interest in computer logic might find this interesting.
This paper introduces ptarithmetic (short for "polynomial time arithmetic") - a formal number theory similar to the well known Peano arithmetic, but based on the recent, computability logic instead of classical logic.
The arithmetic primitives defined in this theory, compute in polynomial time (as against classical logic, operations in which can compute in exponential or combinatorial time).
This paper introduces ptarithmetic (short for "polynomial time arithmetic") - a formal number theory similar to the well known Peano arithmetic, but based on the recent, computability logic instead of classical logic.
The arithmetic primitives defined in this theory, compute in polynomial time (as against classical logic, operations in which can compute in exponential or combinatorial time).
An ideal compiler architecture
I found the compiler architecture description here, http://lambda.uta.edu/cse5317/notes/node5.html to be the most appealing from all the definitions I have read upto now.
Particularly I like the following idea:
"Suppose that you want to build compilers for n programming languages (eg, FORTRAN, C, C++, Java, BASIC, etc) and you want these compilers to run on m different architectures (eg, MIPS, SPARC, Intel, alpha, etc). If you do that naively, you need to write n*m compilers, one for each language-architecture combination.
The holly grail of portability in compilers is to do the same thing by writing n + m programs only. How? You use a universal Intermediate Representation (IR) and you make the compiler a two-phase compiler. An IR is typically a tree-like data structure that captures the basic features of most computer architectures. The first phase of this compilation scheme, called the front-end, maps the source code into IR, and the second phase, called the back-end, maps IR into machine code. That way, for each programming language you want to compile, you write one front-end only, and for each computer architecture, you write one back-end. So, totally you have n + m components."
Though the above idea of compiler construction is quite ideal, the author cautions with these statements:
"But the above ideal separation of compilation into two phases does not work very well for real programming languages and architectures. Ideally, you must encode all knowledge about the source programming language in the front end, you must handle all machine architecture features in the back end, and you must design your IRs in such a way that all language and machine features are captured properly."
I guess, this is something interesting to think about. How good it will be, if all major programming languages translate to the same intermediate representation.
Particularly I like the following idea:
"Suppose that you want to build compilers for n programming languages (eg, FORTRAN, C, C++, Java, BASIC, etc) and you want these compilers to run on m different architectures (eg, MIPS, SPARC, Intel, alpha, etc). If you do that naively, you need to write n*m compilers, one for each language-architecture combination.
The holly grail of portability in compilers is to do the same thing by writing n + m programs only. How? You use a universal Intermediate Representation (IR) and you make the compiler a two-phase compiler. An IR is typically a tree-like data structure that captures the basic features of most computer architectures. The first phase of this compilation scheme, called the front-end, maps the source code into IR, and the second phase, called the back-end, maps IR into machine code. That way, for each programming language you want to compile, you write one front-end only, and for each computer architecture, you write one back-end. So, totally you have n + m components."
Though the above idea of compiler construction is quite ideal, the author cautions with these statements:
"But the above ideal separation of compilation into two phases does not work very well for real programming languages and architectures. Ideally, you must encode all knowledge about the source programming language in the front end, you must handle all machine architecture features in the back end, and you must design your IRs in such a way that all language and machine features are captured properly."
I guess, this is something interesting to think about. How good it will be, if all major programming languages translate to the same intermediate representation.
Saturday, February 21, 2009
Some thoughts about IPv6
I read an article at IANA about the current state of IPv6 implementation on the world wide internet. I just thought of sharing few points here, as mentioned in the IANA IPv6 report, to help spread some awareness about this important issue. The article presents following facts:
1. IPv4 (the current traditional sceme of IP address allocation) theoretically has address space of about 4-5 billion IP addresses. When this scheme was designed, when the modern internet came into existence, it was imagined that about 4-5 billion devices will be a good maximum limit to the number of devices which can be connected to the internet.
But with the growing popularity of the internet across the world, the IPv4 scheme has proved to be insufficient to scale the internet using new devices. By Oct 2007, only 17% IP addresses were available for allocation under IPv4 scheme. Somewhere in 2010-11, all the IPv4 addresses will be exhausted. So after that time, it will be inevitable for the world to shift to IPv6 scheme to add more IP devices to the internet.
Apart from computer machines needing to connect to internet, many different kind of devices are now being designed to have IP capability (like many home appliances for example). To be able to assign all these new devices the globally unique IP addresses, adoption of IPv6 is bound to take place.
2. During the transition period from IPv4 to IPv6, both IPv4 and IPv6 hosts can continue to coexist and interoperate. But interoperation of these two schemes would require investment of time and money from hardware vendors, and network service providers.
The IPv4 scheme is expected to continue in operation for couple of years from now (I guess 5-10 years).
3. The IPv6 support in the softwares seems not to be a problem. Major OS vendors already have IPv6 support built into the OSs. The challenging aspect is the IPv6 support from the hardware and network equipment providers. I am sure that hardware and network vendors who intend to be be in the internet business for a long time in future, will commit the time and money to bring this vital expansion of the internet.
Interestingly, JDK 1.4 and above has provided support for IPv6 based IP addresses. So writing IPv6 enabled client applications is already possible with Java JDK.
Google is also serious about IPv6 adoption. The google search service is now available for IPv6 enabled devices. Please refer, http://googleblog.blogspot.com/2008/05/looking-towards-ipv6.html for more information about Google's efforts to promote IPv6 scheme. http://ipv6.google.com/ is the web URL to do google search from IPv6 machines. If you do a google search from an IPv4 machine (as I do, from the IP address 192.168.1.8) to this host, you'll get an "unknown host error". The machine should have an IPv6 based IP address to access this search service from Google.
1. IPv4 (the current traditional sceme of IP address allocation) theoretically has address space of about 4-5 billion IP addresses. When this scheme was designed, when the modern internet came into existence, it was imagined that about 4-5 billion devices will be a good maximum limit to the number of devices which can be connected to the internet.
But with the growing popularity of the internet across the world, the IPv4 scheme has proved to be insufficient to scale the internet using new devices. By Oct 2007, only 17% IP addresses were available for allocation under IPv4 scheme. Somewhere in 2010-11, all the IPv4 addresses will be exhausted. So after that time, it will be inevitable for the world to shift to IPv6 scheme to add more IP devices to the internet.
Apart from computer machines needing to connect to internet, many different kind of devices are now being designed to have IP capability (like many home appliances for example). To be able to assign all these new devices the globally unique IP addresses, adoption of IPv6 is bound to take place.
2. During the transition period from IPv4 to IPv6, both IPv4 and IPv6 hosts can continue to coexist and interoperate. But interoperation of these two schemes would require investment of time and money from hardware vendors, and network service providers.
The IPv4 scheme is expected to continue in operation for couple of years from now (I guess 5-10 years).
3. The IPv6 support in the softwares seems not to be a problem. Major OS vendors already have IPv6 support built into the OSs. The challenging aspect is the IPv6 support from the hardware and network equipment providers. I am sure that hardware and network vendors who intend to be be in the internet business for a long time in future, will commit the time and money to bring this vital expansion of the internet.
Interestingly, JDK 1.4 and above has provided support for IPv6 based IP addresses. So writing IPv6 enabled client applications is already possible with Java JDK.
Google is also serious about IPv6 adoption. The google search service is now available for IPv6 enabled devices. Please refer, http://googleblog.blogspot.com/2008/05/looking-towards-ipv6.html for more information about Google's efforts to promote IPv6 scheme. http://ipv6.google.com/ is the web URL to do google search from IPv6 machines. If you do a google search from an IPv4 machine (as I do, from the IP address 192.168.1.8) to this host, you'll get an "unknown host error". The machine should have an IPv6 based IP address to access this search service from Google.
Wednesday, February 11, 2009
DOM vs JAXB
The DOM API and JAXB (Java Architecture for XML Binding) look a bit similar to me, for the task of mapping Java objects to XML documents (the concept popularly known as, XML data binding).
JAXB essentially does [1],
1. Marshalling of Java objects to XML.
2. Unmarshalling of the XML data to Java objects.
The DOM API also does [2],
1. Transformation of DOM tree to XML (known as the XML serialization process).
2. Transforming of XML documents to a DOM object tree.
At a broad level, the approaches [1] and [2] look similar.
But according to me, following are the differences between the two approaches:
1. The JAXB transformation is driven by a Schema. The JAXB binding compiler generates Java type definitions for the Schema components. With JAXB, the object model (generated by the JAXB framework) maps closely to the concepts in the problem domain (for e.g, there will be a Java class PurchaseOrder corresponding to a Schema type PurchaseOrder).
Whereas with DOM, the Schema does not drive the XML and Java mapping. And, all the elements in an XML document map to the DOM class, org.w3c.dom.Element. The name of the element, the data inside it and other properties of the element are accessible using the methods provided by the DOM API.
2. There are perhaps some performance differences between JAXB and DOM. A study about this has been done by Santiago Pericas-Geertsen, as shared in these blog posts.
http://weblogs.java.net/blog/spericas/archive/2005/12/dom_vs_jaxb_per.html
http://weblogs.java.net/blog/spericas/archive/2005/12/dom_vs_jaxb_per_1.html
Under certain circumstances (to my opinion), the XML data bindings needs can be met by the DOM API (where a Schema does not drive the data binding process, and a raw mapping of XML and Java is required).
JAXB essentially does [1],
1. Marshalling of Java objects to XML.
2. Unmarshalling of the XML data to Java objects.
The DOM API also does [2],
1. Transformation of DOM tree to XML (known as the XML serialization process).
2. Transforming of XML documents to a DOM object tree.
At a broad level, the approaches [1] and [2] look similar.
But according to me, following are the differences between the two approaches:
1. The JAXB transformation is driven by a Schema. The JAXB binding compiler generates Java type definitions for the Schema components. With JAXB, the object model (generated by the JAXB framework) maps closely to the concepts in the problem domain (for e.g, there will be a Java class PurchaseOrder corresponding to a Schema type PurchaseOrder).
Whereas with DOM, the Schema does not drive the XML and Java mapping. And, all the elements in an XML document map to the DOM class, org.w3c.dom.Element. The name of the element, the data inside it and other properties of the element are accessible using the methods provided by the DOM API.
2. There are perhaps some performance differences between JAXB and DOM. A study about this has been done by Santiago Pericas-Geertsen, as shared in these blog posts.
http://weblogs.java.net/blog/spericas/archive/2005/12/dom_vs_jaxb_per.html
http://weblogs.java.net/blog/spericas/archive/2005/12/dom_vs_jaxb_per_1.html
Under certain circumstances (to my opinion), the XML data bindings needs can be met by the DOM API (where a Schema does not drive the data binding process, and a raw mapping of XML and Java is required).
Subscribe to:
Posts (Atom)