XML Schema Class

I received the latest installment of my online XML course. This class was on XML Schemas. It mentioned that XML started with just Document Type Definitions (DTDs). However the DTD is specified in a format different than XML. However the newer XML Schema is actually written in XML format.

The XML Schema is used to define text data within an XML document. You can define elements of simple type. You can also define elements which have subelements. These are called complex types. There are also built in types which come with XML Schema.

Overall I found this class to be a light treatment of a heavy topic. Perhaps there is more information coming in the next class. Let’s get our bearings here for a moment. XML Schema is used for XML document validation. This validation is performed by the parser. It checks the structure and content of an XML document. In other words it looks at the grammar.

XML Schema itself was approved by the W3C back in 2001. To add to what the class taught, simple types can only have text. They cannot contain attributes. Furthermore, elements from schema must have a namespace qualification. This class glossed over or did not even cover some details such as compositors and facets. I think I mentioned these in an earlier post on my blog. Maybe I will write a separate post to cover them in more detail.

DTDs

This week’s lesson in my online XML course was on Document Type Definitions (DTDs). They are required for well formed XML documents. The DTD is an XML file itself. It is the grammar of your XML document. The DTD provides structure and meaning to the XML document.

The DTD describes your language. Validation is the process of comparing your XML document to the DTD. If you follow the rules in the DTD, your document is known as being valid.

A good way for developing a DTD is to first write your XML document. Then you can spot the patterns and structure required. You can then go back and write a DTD for future XML documents of the same kind.

The DTD is made up of elements, entities, attributes, and notations. This week we went a little further into what constitutes an element. There are actually three types of elements: simple, compound, and stand alone. Perhaps I shall go into more detail about these types in a future post.

XHTML

I caught an article on Dev Archive by Tina Holmboe entitled “XTML – Myths and Reality”. I found this to be of interest given my XML activities recently. So I thought I would review some of the things she said, and figure out whether XHTML is in my future.

The article was geared toward newbies in the field of XHTML. That means it is for me. It started by reviewing that SGML is too complex. HTML was made easy to use. XML was also made for easy implementation. It also clarified that XML is not an SGML application. XML is a set of conventions for SGML.

The web is moving from an SGML to XML format. One of the reasons for the move is to harness the power of XML namespaces. Shifting gears a bit, HTTP allows data type identification. This tells the client how to deal with data. XTML has its own new content type. This tells the client which parser to use on the data.

XHTML is stricter than HTML. There is a lack of XHTML support out there. In fact, no versions of Microsoft’s Internet Explorer support XHTML. That was all I needed to hear to determine that XHTML is not for me. Maybe a better way to put it is that XHTML is not for me just yet. I exclusively use Internet Explorer for everything I do on the web. I wonder why Microsoft is against supporting XHTML.

Attributes

I got another installment from my online XML course. This week we are learning about attributes. They describe the elements. You could say that they provide more information on elements. Attributes are as important as tags. HTML also has attributes. Many HTML attributes deal with margins.

The XML attribute is like an adjective that modifies the element. The syntax is of the format attribute=value. There are several attribute types as follows.

CDATA attributes are character data.

Entity attributes refer to an external item in the XML document.

Enumeration attributes are, as the name implies, a list of values.

Nmtoken attributes are like CDATA, but with more restrictions.

There are also notation attributes. However I have not used them before. Attributes in general are a building block of the XML language. I would consider them second only to elements. You have some choice as to make items elements or attributes. I recall in my formal XML course the instructor went over some guidance on this. Too bad I cannot ask questions in my latest online XML course. This would make for a good discussion.

Elements

I received the latest installment of my online XML course. This week we are covering XML elements. As an aside, I am joining a professional computer association. They state that they have training available for all paid members. One of the courses they teach is XML. So I may have another opportunity to brush up on my XML skills in the future.

The lesson first reviewed the composition of an XML document. It starts with an XML declaration. The rest of the file consists of XML elements. The outermost element is the container element. In a tree notation, each branch of the tree is an element.

The prologue identified that the file is in XML format. The prologue can include validation such as a DTD or XML Schema. It also contains processing instructions.

It is interesting to note that an XML document can contain only one element. In this case, that element would be the containing element. However it would contain no other nested XML elements. This brings up the fact that elements can contain other elements. All elements except the outermost element are contained within the outermost element. However these elements themselves can contain other XML elements.

The concepts of an element and its tags are distinct. Elements can be empty. For such an element, there is short hand syntax to eliminate the full trailing tag. I think it is safe to say that elements are one of the key parts of an XML document.

Parsing

I am on my third class of an online XML tutorial. This week’s topic was XML parsing. This covers how to actually use XML. The parser reads the XML. Some web browsers can parse XML. Internet Explorer version 4 was the first browser to include a parser. Expat is a free XML parser. Lark is a non-validating XML parser written in Java. That’s all the class had to say about parsers. It was pretty light.

So I also went to the W3 schools for some XML parser information. All modern browsers have a built in XML parser. The parser can convert XML into a DOM object. The parser traverses XML trees. I also looked up information about the Expat parser since my online course mentioned it. This XML parser is written in the C programming language. It is stream oriented. Applications register handlers, causing the parser to call back to the application when events of interest occur.

Finally I went to Sun Microsystems to brush up on XML parsers. They were heavily oriented towards parsing with the Java programming language. Data becomes available to the application while the XML is being parsed. SAX makes parsing callbacks available. Your first step is to actually obtain a parser. It should comply with the XML specifications for a parser. Sun recommends the Apache Xerces parser. Xerces is free. It works with both the C and Java programming languages.

Sun says that you should receive the SAX classes along with your parser, as they are parser dependent. The first thing the application needs to do is instantiate the parser. Then you set up callbacks so that SAX can take action on interesting events. This is called registering handlers with SAX. I get the feeling that I actually need to play around with this some more to get a better feeling of how it works.

Channels

Kris Zyp has written some interesting entries on the Comet Daily blog that have to do with channels. The first I saw had to do with HTTP Channels. It is a “publish and subscribe” model to communicate resource changes using HTTP.

Kris has also written about JSON Channels. They are an extension to JSON-RPC. They provide a subscription capability as well. However they are easier to implement than HTTP Channels, as you do not have to parse the HTTP protocol. It can be thought of as an alternative format to HTTP Channels.

In another post, Kris introduces REST Channels. The plan here is to use the web sockets protocol from HTTP 5. However the data is in JSON format. You can mix HTTP and JSON in a browser session. So an efficient technique could use HTTP requests, with updates coming back in JSON format.

I do not want to get too deep into the details. The Comet Daily blog is the source for that. However it is interesting to see that HTTP is still a continual force in the web. However I found it interesting to see that people consider its format a chore for parsing. I have heard colleagues mention how JSON is a good and light format for the web.

I myself am trying to get into web development to prepare myself for where my current project is going. So I am going to need a good handle on all the technology involved. It seems this might be a bit more than just learning XML and its supporting technologies. At least I will have to do a lot of homework to be able to speak intelligently at the architecture level.