The specific method calls for validating instance documents against schemas comprise an area beyond the scope of the current W3C Recommendations. So, we won't find many design issues in common between our Java and C++ implementations . However, there are a few.

The first issue is to decide where to put the schema files. We have a few options.

  • Host them on the Internet at Addison-Wesley's Web site: Probably okay, but that site isn't really set up for this kind of thing (nor is it meant to be). In addition, there are some problems with putting things on the Internet. You have to have a network connection up and running, which might not always be the case for someone using a dial-up service. Files on the Internet require a different base URL than local files, so we would have to accommodate both styles. Some APIs handle these details transparently for us, while others may not.

  • Host them on my site or someplace such as SourceForge: Okay, and probably easier to manage, but with this choice the files are still on the Internet.

  • Host them locally on your computer: All around a better idea. You don't have to have a network connection up and running, you can easily place your own schemas there, and it makes coding a bit easier.

Even with locally hosted schema files, you can still read and validate an input instance document against a schema hosted somewhere else on the Internet. I'm just not going out of my way to code things so that you can create an instance document that way. It might work with the current versions of JAXP and MSXML, but it might not. Again, you can transform your document with XSLT if you need to use a schema on the Internet.

That decided, in order to accommodate as many runtime environments as possible we'll use a local environment variable to specify the base URL of our schemas: BBSCHEMAS (for Babel Blaster schemas). For most shells used on UNIX systems this is done by assigning a value to the variable and optionally exporting it, for example:

 BBSCHEMAS=/babelblaster/schemas; export BBSCHEMAS 

For WIN32 systems, you can use a set statement from the command line or set it through the appropriate control panel function. For example, on my Windows NT system, from System in the Control Panel, on the Environment tab, I set a User Variable for BBSCHEMAS with the following file URL:


The BBSCHEMAS Environment Variable and Java

OK, put me on the side of those who think that deprecating System.getenv was a pretty goofy idea. Yeah, I know, some operating system platforms don't have anything that corresponds to an environment variable. However, removing the functionality makes life a bit more difficult for those of us who work on platforms that do support it.

The bottom line is that we still need a parameter specifying the schema file path that is configurable by the user at runtime. So, for the Java environment we'll use System.getProperty and specify the -D option when we invoke the Java virtual machine. For example, when I run the modified utilities in this chapter I run:

java -DBBSCHEMAS=file:///E:/book/schemas/ classname, etc.

Or, in a script on WIN32 I run:

java -DBBSCHEMAS=%BBSCHEMAS% classname, etc.

Figure out what works best for you, and thank you very much, Sun.

The other design aspect shared by both implementations is the need to write the schema file reference to the output instance document. As we saw in the previous chapter, to do this we add two Attributes to the root Element of the document. This is done in the main routine of CSVToXMLBasic, immediately after creating the root Element and appending it to the Document Node. The first of the two Attributes declares the XMLSchema-instance namespace. To set this we call the root Element's setAttribute method, passing the Attribute name of xmlns:xsi and the URI value of the xsi namespace. For the second Attribute we set the value of an Attribute that lives in that namespace, noNamespace SchemaLocation. Because the Attribute is from a different namespace we need to use the DOM Element's setAttributeNS method, which takes three arguments. The first is the namespace URI of the Attribute, the full URI value of the xsi namespace. The second is the qualified name of the Attribute, that is, the prefix and the local name . The third is the Attribute value. Here's the pseudocode.

Logic to Add Schema- related Attributes
 Root Element <- Call Document's createElement method, with     tagName of SimpleCSV Document <-  Call Document's appendChild to append Root to     Document Root Element <- Call Element's setAttribute method, with     arguments of xmlns:xsi and Root Element <- Call Element's setAttributeNS method, with     arguments of,     xsi:noNamespaceSchemaLocation, and     the URL of our schema file 

CAUTION MSXML Doesn't Support setAttributeNS

This is one area where MSXML lags behind Xerces in standards support. It's kind of a "gotcha" if you don't watch out for it. See the discussion below in the C++ Implementation section.

The other thing we need to do that is common to both implementations is to handle the new command line options. This is pretty plain- vanilla Java and C++, so I won't talk about it further here.

As a final word, since we're starting to build a more capable system and getting to more complex options, I'm adopting a different naming scheme for the root Element. For this chapter and these two more capable utilities I'm going to use CSVFile instead of SimpleCSV.

Using XML with Legacy Business Applications
Using XML with Legacy Business Applications
ISBN: 0321154940
EAN: 2147483647
Year: 2003
Pages: 181

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: