I spent few hours, discovering this while working with the DOM XML parsing API, and using it with Xerces-J, in a Java program.
I wanted to parse an XML document in Java using a plain DOM parser, along with doing validation, using either W3C XML Schema or a DTD.
Following is a sequence of instructions which needs to be written for this:
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setNamespaceAware(true);
dbf.setValidating(true);
SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema ...
dbf.setSchema(schema);
DocumentBuilder docBuilder = dbf.newDocumentBuilder();
docBuilder.parse(..
These statements, are all that are necessary to accomplish this task. But there, are few catches here, which I wish to share.
1) If dbf.setValidating(true) is specified, then a DTD is mandatory. Even if W3C XML Schema is provided with dbf.setSchema .., parsing would fail, since dbf.setValidating(true) was specified, and if a DTD is absent.
2) If we only want to do validation with W3C XML Schema, then we shouldn't specify dbf.setValidating(true), which is required only for DTD validation.
I spent a few hours discovering this, and thought that somebody might benefit from this post.
Saturday, August 22, 2009
Saturday, August 8, 2009
XML Schema 1.1: inheritable attributes, and it's implementation in Apache Xerces-J
The XML Schema 1.1, language has defined a new facility to define attributes as inheritable.
The XML Schema, attribute definition(s) can now specify an additional property (in 1.1 version of the XML Schema language), inheritable (having a schema type, xs:boolean), which will indicate that all the descendant elements to the element (which specifies an inheritable attribute), can access the inheritable attribute by it's name.
It could first appear to the reader of the XML Schema 1.1 spec, that inheritable attributes are something, which can physically be present (i.e., a copy of it) on descendant elements. But this is not the correct interpretation of the inheritable attributes concept. I'll try to illustrate this point with few examples in this post.
Please consider the following XML Schema 1.1, fragment:
This corresponds to, an XML structure like following:
The above XML Schema 1.1 fragment, indicates that attribute, "attr" is inheritable. The word inheritable seems to convey, that the following XML fragment could be valid as well, for the above XML Schema 1.1 fragment:
But this interpration of inheritable attributes is not correct. The inheritable attributes, cannot be physically copied to the descendant elements. In the above examples, the Schema type of element, "Y" is a simple type (i.e., xs:string). So how, could Y have an attribute, "attr" (since by definition, elements with simple types cannot have attributes)? Only XML Schema "complex types", can specify attributes. XML Schema 1.1, inheritable attributes do not change the nature of XML Schema simple types, and simple contents. The presence of attributes on any XML element, is governed only by the attribute declarations on the complex type definition of the element. This meaning for attributes with respect to XSD complex types is preserved, in XML Schema 1.1 as well.
Then it's interesting to think, that what could be the use of specifying the attribute as inheritable (when it cannot be physically present in the descendant elements)?
Inheritable attributes, are useful in a XML Schema 1.1 facility, like Conditional Type Assignment (CTA) / type alternatives.
Please consider the following XML Schema 1.1 example, defining an XML element and it's Schema type, using CTA and inheritable attributes:
As per the above Schema (using type alternatives), the following XML instance is valid:
But the following XML instance would be invalid:
The inheritable attribute is also particularly useful, to define the attribute xml:lang as inheritable in XML elements.
I got to know these facts, after raising a query last week, to W3C XML Schema comments forum.
I am thankful to following gentlemen, for answering my queries, on the W3C XML Schema forum:
C. M. Sperberg-McQueen
Noah Mendelsohn
Michael Kay
The fact, which I really wanted to share on this blog post (other than, sharing what the XML Schema, inheritable attributes are used for), was that I've written an implementation of inheritable attributes, for Apache Xerces-J's XML Schema 1.1 validator. I've submitted a patch for this, to Apache Xerces-J JIRA issue tracking system.
This patch currently, has a full implementation of attribute syntax changes (i.e, the presence of inheritable attribute itself, and it's binding with the XML Schema type, xs:boolean).
I'm in a process to, enhance the Xerces-J implementation of Conditional Type Assignment (CTA) facility, to be able to use inheritable attributes. I hope to complete the CTA changes in Xerces-J, for inheritable attributes in near future.
After all necessary reviews are done for this patch, by Xerces-J committers, I hope to have the inheritable attributes implementation, go to Xerces-J SVN repository, which will in most likelihood subsequently become part of an official future release, of Xerces-J.
2009-08-14: Today, I submitted all the Conditional Type Assignment (CTA) related changes, for inheritable attributes, to Apache Xerces-J JIRA issue tracking system. I would say, the XML Schema 1.1 inheritable attributes, and it's integration with CTA is completed, for Xerces-J. I'm feeling good about it :)
The XML Schema, attribute definition(s) can now specify an additional property (in 1.1 version of the XML Schema language), inheritable (having a schema type, xs:boolean), which will indicate that all the descendant elements to the element (which specifies an inheritable attribute), can access the inheritable attribute by it's name.
It could first appear to the reader of the XML Schema 1.1 spec, that inheritable attributes are something, which can physically be present (i.e., a copy of it) on descendant elements. But this is not the correct interpretation of the inheritable attributes concept. I'll try to illustrate this point with few examples in this post.
Please consider the following XML Schema 1.1, fragment:
<xs:element name="X">
<xs:complexType>
<xs:sequence>
<xs:element name="Y" type="xs:string" />
</xs:sequence>
<xs:attribute name="attr" type="xs:int" inheritable="true" />
</xs:complexType>
</xs:element>
This corresponds to, an XML structure like following:
<X attr="1">
<Y>hello</Y>
</X>
The above XML Schema 1.1 fragment, indicates that attribute, "attr" is inheritable. The word inheritable seems to convey, that the following XML fragment could be valid as well, for the above XML Schema 1.1 fragment:
<X attr="1">
<Y attr="1">hello</Y>
</X>
But this interpration of inheritable attributes is not correct. The inheritable attributes, cannot be physically copied to the descendant elements. In the above examples, the Schema type of element, "Y" is a simple type (i.e., xs:string). So how, could Y have an attribute, "attr" (since by definition, elements with simple types cannot have attributes)? Only XML Schema "complex types", can specify attributes. XML Schema 1.1, inheritable attributes do not change the nature of XML Schema simple types, and simple contents. The presence of attributes on any XML element, is governed only by the attribute declarations on the complex type definition of the element. This meaning for attributes with respect to XSD complex types is preserved, in XML Schema 1.1 as well.
Then it's interesting to think, that what could be the use of specifying the attribute as inheritable (when it cannot be physically present in the descendant elements)?
Inheritable attributes, are useful in a XML Schema 1.1 facility, like Conditional Type Assignment (CTA) / type alternatives.
Please consider the following XML Schema 1.1 example, defining an XML element and it's Schema type, using CTA and inheritable attributes:
<xs:element name="X">
<xs:complexType>
<xs:sequence>
<xs:element name="Y" type="xs:anyType">
<xs:alternative test="@attr = 'INT'" type="xs:int" />
<xs:alternative type="xs:error" />
</xs:element>
</xs:sequence>
<xs:attribute name="attr" type="xs:int" inheritable="true" />
</xs:complexType>
</xs:element>
As per the above Schema (using type alternatives), the following XML instance is valid:
<X attr="INT">
<Y>100</Y>
</X>
But the following XML instance would be invalid:
<X attr="INT">
<Y>hello</Y>
</X>
The inheritable attribute is also particularly useful, to define the attribute xml:lang as inheritable in XML elements.
I got to know these facts, after raising a query last week, to W3C XML Schema comments forum.
I am thankful to following gentlemen, for answering my queries, on the W3C XML Schema forum:
C. M. Sperberg-McQueen
Noah Mendelsohn
Michael Kay
The fact, which I really wanted to share on this blog post (other than, sharing what the XML Schema, inheritable attributes are used for), was that I've written an implementation of inheritable attributes, for Apache Xerces-J's XML Schema 1.1 validator. I've submitted a patch for this, to Apache Xerces-J JIRA issue tracking system.
This patch currently, has a full implementation of attribute syntax changes (i.e, the presence of inheritable attribute itself, and it's binding with the XML Schema type, xs:boolean).
I'm in a process to, enhance the Xerces-J implementation of Conditional Type Assignment (CTA) facility, to be able to use inheritable attributes. I hope to complete the CTA changes in Xerces-J, for inheritable attributes in near future.
After all necessary reviews are done for this patch, by Xerces-J committers, I hope to have the inheritable attributes implementation, go to Xerces-J SVN repository, which will in most likelihood subsequently become part of an official future release, of Xerces-J.
2009-08-14: Today, I submitted all the Conditional Type Assignment (CTA) related changes, for inheritable attributes, to Apache Xerces-J JIRA issue tracking system. I would say, the XML Schema 1.1 inheritable attributes, and it's integration with CTA is completed, for Xerces-J. I'm feeling good about it :)
Thursday, July 30, 2009
Grady Booch: about Linux, and TTY interfaces
Reading through Grady Booch's latest blog post, I found that Grady has shared interesting information about TTY interfaces in Linux, and of UNIX based systems.
I read the article, which Grady pointed, almost completely and found it a great read.
Something interesting to share, I thought!
I read the article, which Grady pointed, almost completely and found it a great read.
Something interesting to share, I thought!
Saturday, July 18, 2009
Niklaus Wirth: On current state of software development, and future
Navigating from Dr. Niklaus Wirth's wikipedia web page, I could find a very interesting interview conversation, Dr. Wirth had, on the following web site (ref, http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html).
This interview is dated, in 1997. I found Dr. Wirth's views in this interview, quite good to read.
Something interesting to share, I thought!
This interview is dated, in 1997. I found Dr. Wirth's views in this interview, quite good to read.
Something interesting to share, I thought!
Sunday, July 12, 2009
Niklaus Wirth: On recursive algorithms
I have started reading the computer science, classic collection "ALGORITHMS + DATA STRUCTURES = PROGRAMS" by Niklaus Wirth. Dr. Wirth wrote this text in 1975. It's a great book.
Though "recursive algorithms" are widely known to computer science community since long time, I still could find some good advice in Dr. Wirth's book on usage of recursive algorithms.
Dr. Wirth mentions:
"An object is said to be recursive if it partially consists or is defined in terms of itself. Recursion is a particularly powerful means in mathematical definitions. The power of recursion evidently lies in the possibility of defining an infinite set of objects by a finite statement. In the same manner, an infinite number of computations can be described by a finite recursive program, even if this program contains no explicit repetitions."
We all know, what recursive algorithms are. It's a widely known programming technique. But I found particularly the advice, "When not to use recursion" in Dr. Wirth's book very worth while to apply.
Dr. Wirth further mentions:
"Recursive algorithms are particularly appropriate when the underlying problem or the data to be treated are defined in recursive terms. This does not mean, however, that such recursive definitions guarantee that a recursive algorithm is the best way to solve the problem.
Programs in which the use of algorithmic recursion is to be avoided can be characterized by a schema which exhibits the pattern of their composition. Such schema's can described as following:
[1]
P => if B then (S; P)
or, equivalently
P => (S; if B then P)
"
Dr. Wirth illustrates this principle with a well known, recursive definition of the factorial computation (mentioned below):
F0 = 1
F(i+1) = (i + 1) * f(i)
Dr. Wirth maps the factorial problem with the recursive anti-pattern he defines ([1] above):
[2]
P => if I < n then (I := I + 1; F := I * F; P)
I := 0; F := 1; P
In the above definition [2], S (ref, [1]) refers to,
I := I + 1; F := I * F
Dr. Wirth in the book, illustrates a following, iterative definition of factorial computation:
Dr. Wirth says, "The lesson to draw is to avoid the use of recursion when there is an obvious solution by iteration.
This, however, should not lead to shying away from recursion at any price. The fact that implementations of recursive procedures on essentially non-recursive machines exists proves that for practical purposes every recursive program can be transformed into a purely iterative one. This, however, involves the explicit handling of a recursion stack, and these operations will often obscure the essence of a program to such an extent that it becomes most difficult to comprehend. The lesson is that algorithms which by their nature are recursive rather than iterative should be formulated as recursive procedures."
Just thought of sharing a bit of text, from this nice book and encouraging readers to read the book!
Though "recursive algorithms" are widely known to computer science community since long time, I still could find some good advice in Dr. Wirth's book on usage of recursive algorithms.
Dr. Wirth mentions:
"An object is said to be recursive if it partially consists or is defined in terms of itself. Recursion is a particularly powerful means in mathematical definitions. The power of recursion evidently lies in the possibility of defining an infinite set of objects by a finite statement. In the same manner, an infinite number of computations can be described by a finite recursive program, even if this program contains no explicit repetitions."
We all know, what recursive algorithms are. It's a widely known programming technique. But I found particularly the advice, "When not to use recursion" in Dr. Wirth's book very worth while to apply.
Dr. Wirth further mentions:
"Recursive algorithms are particularly appropriate when the underlying problem or the data to be treated are defined in recursive terms. This does not mean, however, that such recursive definitions guarantee that a recursive algorithm is the best way to solve the problem.
Programs in which the use of algorithmic recursion is to be avoided can be characterized by a schema which exhibits the pattern of their composition. Such schema's can described as following:
[1]
P => if B then (S; P)
or, equivalently
P => (S; if B then P)
"
Dr. Wirth illustrates this principle with a well known, recursive definition of the factorial computation (mentioned below):
F0 = 1
F(i+1) = (i + 1) * f(i)
Dr. Wirth maps the factorial problem with the recursive anti-pattern he defines ([1] above):
[2]
P => if I < n then (I := I + 1; F := I * F; P)
I := 0; F := 1; P
In the above definition [2], S (ref, [1]) refers to,
I := I + 1; F := I * F
Dr. Wirth in the book, illustrates a following, iterative definition of factorial computation:
I := 0;
F := 1;
while I < n do
begin I := I + 1; F := I * F
end
Dr. Wirth says, "The lesson to draw is to avoid the use of recursion when there is an obvious solution by iteration.
This, however, should not lead to shying away from recursion at any price. The fact that implementations of recursive procedures on essentially non-recursive machines exists proves that for practical purposes every recursive program can be transformed into a purely iterative one. This, however, involves the explicit handling of a recursion stack, and these operations will often obscure the essence of a program to such an extent that it becomes most difficult to comprehend. The lesson is that algorithms which by their nature are recursive rather than iterative should be formulated as recursive procedures."
Just thought of sharing a bit of text, from this nice book and encouraging readers to read the book!
Saturday, July 4, 2009
PsychoPath XPath 2.0 processor update
Dave Carver and I have been trying to improve the Eclipse XPath 2.0 processor (a.k.a PsychoPath) during last couple of weeks. My motivation to keep working on PsychoPath engine has been a desire, to help Eclipse and Apache (Apache Xerces-J uses PsychoPath engine for XML Schema 1.1 processing) communities to be able to have a highly compliant XPath 2.0 engine.
Dave has written today, a progress update of PsychoPath development on this blog. I feel, we now have a pretty good XPath 2.0 implementation with PsychoPath. We are continuing to work on remaining non-compliant items, with PsychoPath. The remaining non compliance cases, to my opinion are near edge cases which users don't use too often. But we'll continue to solve them, with each future day and weeks.
Update on 2009-07-11: During last couple of days, Dave Carver has made quite a few useful improvements to PsychoPath, and the W3C XPath 2.0 test suite within Eclipse. I took an update today of the latest PsychoPath sources, and the XPath 2.0 test suite, and following are the latest test results:
Total tests: 8137
Failures: 811
Errors: 48
This reflects, the test pass success rate of about 89.5%. I think, this is quite good. Lot of credit of these improvements should go to Dave Carver. Dave has single handedly, created a JUnit version of the full W3C XPath 2.0 test suite, which is in itself a great feat! Having JUnit tests, helps us tremendously to run the XPath 2.0 tests, from within Eclipse.
Update on 2009-08-09: Following are the current PsychoPath test data:
Total tests: 8137
Failures: 386
Errors: 24
This reflects a test suite pass percentage of about, 95% which looks very impressive. The test suite code coverage, is about 75-80%.
Lot of credit for the latest PsychoPath improvements should go to, "Jesper S Møller" who has recently volunteered to help improve PsychoPath with the XPath 2.0 test suite. Dave Carver is also putting in his time, on PsychoPath improvements.
Dave has written today, a progress update of PsychoPath development on this blog. I feel, we now have a pretty good XPath 2.0 implementation with PsychoPath. We are continuing to work on remaining non-compliant items, with PsychoPath. The remaining non compliance cases, to my opinion are near edge cases which users don't use too often. But we'll continue to solve them, with each future day and weeks.
Update on 2009-07-11: During last couple of days, Dave Carver has made quite a few useful improvements to PsychoPath, and the W3C XPath 2.0 test suite within Eclipse. I took an update today of the latest PsychoPath sources, and the XPath 2.0 test suite, and following are the latest test results:
Total tests: 8137
Failures: 811
Errors: 48
This reflects, the test pass success rate of about 89.5%. I think, this is quite good. Lot of credit of these improvements should go to Dave Carver. Dave has single handedly, created a JUnit version of the full W3C XPath 2.0 test suite, which is in itself a great feat! Having JUnit tests, helps us tremendously to run the XPath 2.0 tests, from within Eclipse.
Update on 2009-08-09: Following are the current PsychoPath test data:
Total tests: 8137
Failures: 386
Errors: 24
This reflects a test suite pass percentage of about, 95% which looks very impressive. The test suite code coverage, is about 75-80%.
Lot of credit for the latest PsychoPath improvements should go to, "Jesper S Møller" who has recently volunteered to help improve PsychoPath with the XPath 2.0 test suite. Dave Carver is also putting in his time, on PsychoPath improvements.
Friday, June 26, 2009
Multiple inheritance in Java
I have always missed true multiple inheritance in Java (like, in C++). For e.g., we are not able to define a class as follows in Java:
class X extends A, B, C {
}
Though, I do not see any inheritance use case which cannot be solved by the current Java facilities, but I would love to have this facility in Java. I think, the most latest Java version (1.7) doesn't have this feature.
One workaround I can see, for multiple inheritance, is to define a class like following:
class X {
A a;
B b;
C c;
}
i.e., we could create private class members inside X (whose functionality we want to use in class X).
Though this might serve purpose for some of the cases, but it's not true multiple inheritance! This I think, is actually aggregation pattern.
Of course, Java has multiple inheritance of interfaces. But that is inheritance of method signatures, and not of implementation.
I guess, keeping the number of base classes to one, Java is much simpler syntactically, and has a simpler compiler implementation. Though I agree, that having a simple syntax (as the current Java inheritance facilities) which is powerful enough, and can solve many use cases is better, than having a complex syntactical facility, which might serve even more uses cases, but could also lead to semantically difficult programs, which may be difficult to maintain and debug, as complexity of the problem domain increases.
class X extends A, B, C {
}
Though, I do not see any inheritance use case which cannot be solved by the current Java facilities, but I would love to have this facility in Java. I think, the most latest Java version (1.7) doesn't have this feature.
One workaround I can see, for multiple inheritance, is to define a class like following:
class X {
A a;
B b;
C c;
}
i.e., we could create private class members inside X (whose functionality we want to use in class X).
Though this might serve purpose for some of the cases, but it's not true multiple inheritance! This I think, is actually aggregation pattern.
Of course, Java has multiple inheritance of interfaces. But that is inheritance of method signatures, and not of implementation.
I guess, keeping the number of base classes to one, Java is much simpler syntactically, and has a simpler compiler implementation. Though I agree, that having a simple syntax (as the current Java inheritance facilities) which is powerful enough, and can solve many use cases is better, than having a complex syntactical facility, which might serve even more uses cases, but could also lead to semantically difficult programs, which may be difficult to maintain and debug, as complexity of the problem domain increases.
Subscribe to:
Posts (Atom)