Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Get a Jump on XML Development  : Page 3

Taking advantage of XML's power requires a mind shift. Get used to thinking differently about markup languages.


advertisement
Putting it All Together
So, what does our software description document look like when it's all put together? Listing 2 shows the final results. You'll notice that an XML declaration (<?XML VERSION="1.0 ?>) begins the document. This specifies what version of XML the document was written for. The DTD portion of the document begins with <!DOCTYPE software. This declaration indicates that the DTD is about to begin and that the document element for the document is software. The non-DTD portion of the document always begins with the open document element tag and ends with the close document element tag. The document is set up to contain as many other package descriptions as necessary as long as they all fall between the <SOFTWARE>...</SOFTWARE> tags

The DTD portion of the document doesn't always have to be stored inside the document. Instead the DTD can be saved in its own file for reference by several different documents. If I removed the DTD from the document and saved it in a file called software.dtd, the new internal DTD reference for this document would use this syntax:

<!DOCTYPE software SYSTEM "software.dtd>

The document element software is still the same, but the SYSTEM portion of the DOCTYPE declaration indicates the DTD is stored in an external file called software.dtd.

This example provides only the most basic introduction to the structures of an XML document, but you have to start somewhere (see the sidebar "Selecting the Right XML Vocabulary"). All XML documents are a variation on this theme. Different vocabularies provide the DTD, but the structures are defined in the same manner and invoked in the document element with tags. Once you learn how to read DTD and write quality markup the rest is just knowing what tag does what, and that's nothing new in the web world.

XML Design vs. HTML Design
To design flawless XML documents, web page developers will have to leave many of their old HTML habits behind and learn to use markup languages as intended. Even veteran page designers might be shocked to know that they've been using HTML incorrectly all this time. That is, they've been treating it as a formatting mechanism instead of a description mechanism.

The forgiving nature of web browsers and the focus of books, magazines, and web sites on tips and tricks for controlling the final display of web pages has helped promote HTML as a formatting language. Although mangled HTML markup might lead to tightly controlled, well-designed web pages, mangled XML leads only to heartache.

Start your journey into the XML design world by leaving this HTML baggage behind:

  • Don't do "whatever it takes" to achieve the desired look and feel. This approach to page design is a direct violation of the spirit of markup. Remember, you're describing content, not formatting it.
  • Stop designing for one browser or another. The whole idea behind markup is that documents are created without regard for their final appearance. As long as your documents are well described, they will be rendered correctly.
  • Don't try to force "round" content pegs into "square" markup holes. You're not limited to plain HTML anymore, don't feel you have to force your content to fit any specific notation. Choose the markup that best describes your content and your information processing needs.
  • Don't ignore the rules because the browsers do. By its very nature, XML requires you to follow its rules, and you'll find that if you follow the HTML rules more closely, you'll achieve better overall results in the end.
  • Stop focusing on your document's final look and feel as displayed on a graphical screen. Although the majority of HTML documents are viewed with graphical browsers, they are not limited to GUI interpretation. XML is designed to allow documents to be rendered in a wide variety of ways from computer screens, to text-to-speech readers, to projection systems, to printers.
Of course, designing the document is only half the issue. What about display and implementation issues? A document won't do you any good if you can't share it with others. That's where the realities of implementation set in.

Implementing XML Today
XML is an emerging technology and the majority of parsers and browsers written to process XML documents are experimental at best. Currently, you can't transfer an XML document to your web server, point at it with a URL or hyperlink, and expect the average browser to know what to do with it. For an XML document based on any vocabulary to be rendered by a user agent it must first be parsed, and today's web browsers can only parse and display HTML pages. All other markup is mostly foreign to them.

The creators of the various XML DTD already under development realize that web browsers don't support their documents. To remedy this situation, many of them have developed specialized parsers and browsers, geared specifically to their XML vocabularies, written in Java for embedding in web pages. When you choose an XML vocabulary, you'll want to find out what parsers and tools have been developed to help you display documents written to that vocabulary. For example, the creators of the Chemical Markup Language (CML) have developed a CML browser called Jumbo, as well as a series of applets to parse and view CML documents. Similar activities are underway for many other XML vocabularies that have already been developed.

As a step in the right direction, Microsoft and Netscape have added limited XML support to their browsers. Internet Explorer 4.01 for Windows NT/95/98 ships with a C++ XML parser that can parse a document and pass its results to a Java applet, an ActiveX control, or a web script for rendering. You can also download a Java-based validating parser from Microsoft's web site as an add-in. IE 4.01 also includes the XML Document Object Model (DOM) that makes all the elements in an XML document accessible to web scripts written in JavaScript or VBScript once the document has been parsed. This is the first step in tying XML to Dynamic HTML.

When Netscape released the Mozilla source code for what would have been Navigator 5.0, it included XML support for the Resource Description Framework (RDF) vocabulary. The source code also included a version of James Clark's expat XML parser. Although Netscape's inclusion of XML support in its browser isn't quite as extensive as Microsoft's, it is a good start. Based on the reactions to XML from the two top browser vendors, it's obvious that XML is a legitimate web phenomenon. Look for increased XML support in future versions of both browsers, and from other browser vendors as well (see the sidebar "Real-Life XML: How Microsoft Channels Work").

You might be concerned that XML will inhibit your creativity or limit your page design options. Never fear, XML is going to revolutionize page design by adding whole new groups of markup to your design arsenal. You'll have the right tools available for the job, and that's far better than using the wrong tool because it's the only one you've got. Have you ever tried to pound a nail into a wall with a screwdriver because you didn't have a hammer? XML gives you a hammer, a power saw, a cordless drill, and every other power tool you'd possibly need to design amazingly creative and content-oriented web pages. Don't fear XML, try it!



Natanya Pitts-Moultis is a webmaster, writer, and trainer for LANWrights Inc. Her XML authoring credits include the XML Black Book (Coriolis, September 1998) and XML In Record Time (Sybex, November 1998).
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date