Bringing It All Together


We have examined the XML schema for the employeeList XML and have explained the various elements that make up the schema definition. In this section, we take a look at how the schema is tied to the employeeList XML instance and briefly describe how a simple JAXP program is used to parse and validate the XML.

The targetNamespace declaration signifies that all elements defined in the schema (employeeList, employee, email, etc.) belong to the www.flute.com namespace. In turn, the XML instance document for Flute employeeList signifies that all elements used in the instance document belong to the www.flute.com namespace.

start sidebar

An XML schema document defines schema elements into the target namespace, and an instance document uses the defined elements from that namespace.

end sidebar

The instance document also provides a hint to the XML processor as to the location of the schema, using the schemaLocation attribute. This attribute contains a pair of values separated by whitespace: The first value (http://www.flute.com)is the namespace, and the second (employee.xsd) is the location of the appropriate schema document. Note that the values provided by this attribute are only a hint and that the processor is free to use other schemas obtained by other means.

start sidebar
Why the schemaLocation Attribute Value Is Only a Hint

Acme Manufacturing and Tremont Suppliers, Inc. agree to transact using Web services. Tremont will invoice Acme over the Web, and both parties agree on an invoice schema, invoice.xsd. When Tremont sends an invoice instance document to Acme, it uses the schemaLocation attribute to point to an invoice xsd.

Now, how is Acme to be sure that Tremont is using the agreed-upon schema? Acme has no control over the schema if the only option is to rely on the schemaLocation value set by the sender of the invoice instance document. In the real world, where trust alone is not enough to conduct business, the receiving party must be able to specify the schema to be used.

Acme should use a parser that allows them to override any schemaLocation value specified in the instance document. As an example, see Listing A.2, where the schema location is set as a property to the Xerces parser when it is invoked.

Listing A.2

start example
 SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setValidating(true); factory.setNamespaceAware(true); //apache-specific features to enable XML schema validation factory.setFeature("http://apache.org/xml/features/validation/schema-full- checking",true);       factory.setFeature("http://apache.org/xml/features/validation/schema",true); SAXParser parser = factory.newSAXParser(); //the schemaLocation attribute is only a hint to the parser. this property //links the namespace and provides the location of the physical file. parser.setProperty(     "http://apache.org/xml/properties/schema/external-schemaLocation",      "http://www.flute.com employee.xsd"); parser.parse(new File("employee.xml"),this); 
end example

It is not necessary for a schema to define elements in a namespace (i.e., it is acceptable to have a schema with no targetNamespace attribute). Instance documents that use elements defined without a namespace may use the noNamespaceSchema attribute to provide the process with the location of the schema (e.g., xsi:noNamespaceSchemaLocation = "employee.xsd").

end sidebar

Listing A.2 uses JAXP API to invoke the Apache Xerces validating parser to validate the employee XML with the employee schema. The Xerces parser comes with the JAVA WSDP 1.0 download.




Java Web Services Architecture
Java Web Services Architecture (The Morgan Kaufmann Series in Data Management Systems)
ISBN: 1558609008
EAN: 2147483647
Year: 2005
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net