Validation with Java and XML Schema, Part 3. You've seen it happen. Heck, you've probably been a part of the problem more than a few times yourself. We, as programmers, pride ourselves on lugging our toolbox of code, tips, tricks, and experience to the jobs and projects on which we work. But in every application, when it comes to validation, we seem to lean towards reinventing the wheel. We write and rewrite code, and end up missing out on a great chance to add to our toolboxes. Read the whole . Using the Extensible Markup Language seems to be even more popular than hacking the Linux kernel these days and will even make your boss happy. Validate XML against XSD in Java Here's the sample java program which will validate xml file against a particular schema. So how do those two fit together? Well, XML, and specifically XML Schema, provides a perfect means of detailing constraints for Java data. And with a simple Java- based framework, you can build those constraints into Java objects and compare application data against them. The end result is a flexible, robust, XML- based framework for all your Java validation needs. In this article, I'll show you how to parse an XML Schema and build up a set of constraints. Once those constraints are ready for your Java program to use, I'll detail the process of comparing data to them. Finally, your application will be given a means to pass in data and determine which constraint to apply to that data, indicating if that data is valid for that constraint. But before diving in, let me fill you in on what's already happened in this series. If you missed the premiere. In Part 1, I spent a lot of time talking about validation in general terms. I looked at some common bad practices you tend to find in validation code, particularly the case of simply hard coding in constraints. Of course, that is not at all portable, so I also looked at some utility classes, such as Jason Hunter's Parameter. Parser class from Java Servlet Programming. That class allows the simple conversion from the String format in which servlets receive data to various other Java formats such as ints, floats, and booleans. However, that still did not address other common validation needs such as range checking and specifying only a few allowed values. Finally, I introduced XML as a possible solution, showing how an XML document is superior to Java's standard property files. In Part 2, I introduced the validation framework. Starting with some basic design, I showed the four basic classes you need to code: The Constraint class, which represents constraints for a single type, like the shoe. Size type. The Validator class, which provides an interface for allowing developers to pass in data, and find out if the data is valid. The schema. Parser class, which parses an XML Schema and creates the Constraint objects for use by the Validator class. The Data. Converter helper class, which will convert from XML Schema data types to Java data types, and perform other data type conversions for you. In that article, I showed you the Constraint class in its entirety, providing basic methods that allowed setting an allowed range, a data type, and allowed values for the data. If you were to add additional constraint types, such as pattern matching, you would add them to that class. I also outlined the Validator class, and left a blank where schema parsing would occur, which I will fill in this article. So now you are ready to dive into the guts, right? In this article, I'll start with parsing the XML Schema, and building up constraints. Next, you'll see how to take those constraints and apply them to data in the Validator class. So let's get to it. Parsing the schema. The bulk of the work that you need to do is in the schema. Parser class. That class has one single task: to parse an XML Schema. While it parses, it should take each XML Schema attribute and create a Constraint instance out of it. To refresh your memory, here's a sample XML Schema. That is still based on the shoe store that was discussed in the previous articles but has some additional constraints: < ? That class would have a data type of . Instead, the Constraint class converts that data type (using the Data. Converter class) to the Java equivalent. What's the best way to validate an XML file against an XSD file? The Java runtime library supports validation. This JAXP Java tutorial describes Java API for XML Processing (jaxp). Run the DOMEcho program on an XML file. Or upload it: The validation check is performed against any XML schema or DTD declared inside the XML document. Aplikasi Xml Editor For Java. Try The Online XML Schema Validator From CoreFiling To. XML differences; XML schema validator. Xml Schema Validation Java Code. Although Java Architecture for XML. Validate XML using a XSD (XML Schema. Java program to validate the enumerations in xml and xsd. It will then have a value of 0 for the minimum (exclusive) value, and a value of 2. In that constraint, the minimum (inclusive), maximum (exclusive), and allowed values will all not be used, as they aren't specified; another constraint might specify allowed values but no range at all. So with that in mind, I'll start with looking at the class skeleton. The schema. Parser skeleton. The schema. Parser class has few public methods. The class's constructor takes in a java. URL pointing to the XML Schema to parse. That method will then need to fire off a private method, which will handle the parsing and build up constraints. Once the instance has been constructed and parsing has occurred, the client needs to access the built- up constraints. To allow that, two methods are provided: get. Constraints(), which returns a list of the Constraint objects resulting for a parse, and get. Constraint(String constraint. Name), which returns the Constraint for the supplied name (if it exists). Here, then, is the skeleton for this class. It takes care of importing all the various classes that will be needed, and defines the storage that will be used by the parseschema() method. Once that skeleton is in place, I'll show you how to handle the actual parsing. IOException. import java. URL. import java. Map. import java. Hash. Map. import java. Iterator. import java. List. // JDOM classes used for document representation. Attribute. import org. Document. import org. Element. import org. JDOMException. import org. Namespace. import org. SAXBuilder. import org. Constraint. * The < code> schema. Parser< /code> class parses an XML Schema and creates. If none is found, this. You should notice that the constructor and parseschema() method can both throw an IOException if problems arise. That gives the code a means of reporting problems back up the chain to the client, using the validation framework. It also is the type of Exception that any Java code using the URL class might generate, which means that the code doesn't have to trap for those sorts of errors; instead, they are just thrown up the calling chain. Another important item you should note is the schema. Namespace variable. That variable holds the JDOM Namespace object for the XML Schema namespace. If you look at the XML Schema document again (shown above), the XML Schema namespace URI is assigned to the default namespace. That means that all nonprefixed elements in the schema (which happens to be all elements) are assigned to that default namespace, the XML Schema namespace. Getting the associated JDOM Namespace object for that default, XML Schema, namespace will help you look up items in the document; in the next section, I'll show you how that all fits together. Once you have the skeleton in place, you need to handle actually parsing the XML Schema. I'll discuss that now. XML, schemas, and JDOMThe key to the entire schema. Parser class is being able to (no surprise here) actually parse an XML Schema. Many XML parsers, such as Apache Xerces, currently offer options for schema validation; however, you do not want to use those facilities. In fact, you don't want the XML Schema to be handled as a schema at all. That is because all parsers, at least in their current versions, use vendor- specific structures for handling XML Schemas. The result is nonportable code, the enemy of any Java programmer. Instead, the schema. Parser class can rely on the fact that an XML Schema document is actually an XML document as well. It conforms to XML's well- formedness rules and, therefore, can be treated as any other XML document. Therefore, the schema parser can read in the XML Schema as an XML document and operate on it as it would any other document with which it works. That is exactly what the parseschema() method does. Using JDOM, which you can obtain in Resources, the parseschema() method first uses SAX to read in the supplied schema URL and build a JDOM Document object. And now is when that schema. Namespace variable comes into play (remember I said it would?). The XML Schema attribute construct represents all the constraints, so once the document is read into memory, those constraints are located within the document by simply looking up all elements named attribute (I know, it's sort of confusing, isn't it? All the attribute elements..) in the XML Schema namespace. Then, each of the resulting objects (represented by a JDOM Element) are passed to a utility method, handle. Attribute(). The code shown here puts that into action.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2017
Categories |