Good afternoon, everyone. Can I ask you all a favor? Those of you who have large empty spaces next to you, could you please all kind of stand up and shuffle over a bit? We've got a lot of people who want to come in and see this, and it's not nearly as much fun being in the overflow room. Thank you very much.

So, people in the middle have been very helpful here. Some of you on the edges, kind of try and squeeze in a little bit. One or two seats on the edges makes a big difference, helps people grab a seat and feel like they're part of the crowd here.

One big happy family, right? Okay, so we're here to talk about one of my favorite topics, XML. Just to clarify, some of you have been coming up and asking me about, you know, bug fix orders and engineering standards. I'm the product marketing manager, okay? I'm the marketing weenie for WebObjects and development platforms. I don't know the in-depth guts of all the engineering stuff. Tony or the engineering teams can give you much better answers on that.

I handle all the warm, fuzzy stuff. So, feel free to come hassle me about those things, but just direct your questions appropriately. I'm also responsible for what we do with general development platforms, including open source, Java, and open standards, which is why I'm very excited about this session on XML. How many of you are doing things with XML today? Okay.

How many of you think you're going to have to do stuff with XML in the next year or so? Okay. So, it's definitely coming down the pike. We want to make sure that we have the best platform, WebObjects, Mac OS X, open source. As you know, Apple does have already a C-based XML parser that we've open sourced as part of the Darwin project for Mac OS X for people writing into Mac OS X or core foundation APIs. We also have some very cool Java stuff integrated with WebObjects, which is what Michael will be telling you about right now. So, I introduce -- sorry, Tim Jorison from WebObjects. Thank you very much.

Thanks, Ernie. So what we're going to talk about today is WebObjects and XML. And Ernie kind of stole my questions because everyone seems to be starting out with questions. So I'm going to ask it again except slightly different. I saw a number of hands go up to people doing XML stuff. So just raise those hands again, people doing XML today. Okay. And those of you--no, keep them up, keep them up just for a second. And those of you doing it with WebObjects.

Okay, so about half, half the number of people. Okay, thanks. So, what we're going to do is talk about XML today, and we're going to start out with the basics of XML. So most of you, I think, looking out there, probably know the basics, but I just want to kind of cover that real quick. And then we're going to talk about the mechanics of XML with WebObjects. What kind of facilities are in WebObjects to deal with XML and kind of the typical scenarios.

We're going to talk about encoding and decoding XML. Another way of saying it is perhaps archiving and parsing, reading and vending, consuming and vending. We're going to talk about XML being used for server-to-server communication. There are lots of uses of XML, but what we're going to kind of talk about here is really server-to-server, because that's really where WebObjects has a big, strong role and can do a lot. And we're going to use content syndication, kind of a very simplified version of that, as an example to illustrate using XML with WebObjects.

So first the basics of XML. Back when the web started, it was all about content. The tagging was really to represent the different areas of content. It wasn't about format. What XML brings back to the table is the content. It really is all about the content. And of course there are other ways, ironically, using XML to describe the format of formatting the XML over here, but fundamentally it's about content. It is a tag system, much like HTML. We have tags, except it's a little bit stricter than HTML, more akin to perhaps SGML in its structuredness and rigidity.

It does use plain text, as you're probably aware. And the good thing of all this, the good part of this is that it's not just a text, it's a text that's written in HTML. It's a text that's written in HTML. And the good part of all this is that it really is pretty easy to learn the basics.

Lots of books on XML, and a lot of them don't even talk about programming at all. They really treat it more like, you know, just kind of a structured ASCII document, and how you can interact with this document and have this document represent meaningful and useful information. And it is, it is absolutely gaining a widespread acceptance for, for data interchange, which is really one of the reasons why we're going to focus a little bit on, on that server-to-server communication.

So first a little sample XML file just so we all understand what we see. Looks, we have tags. Here you can see the very top level is a model tag and everything else is enclosed in that. We clearly have tags and attributes. The one thing I will point out for those who are kind of from the HTML arena is if we look at this first property list here where it says the third line down, property name equals quantity.

At the very end, the far right, you'll see that that tag actually has a slash before the end of it. This is an empty tag. So this is something that XML kind of brings to the table and something you haven't seen in your typical HTML document. So there's just a sample bit of XML.

So now let's talk about WebObjects and XML. Traditionally WebObjects is a server and it's used to vend information out. And typically it's vending information out for web pages. So there's this notion of a request and a response. WebObjects 4.5 adds a factoring application to the server role. And in the server role, the WebObjects application takes in requests and sends out responses.

When you start talking about server-to-server communication, all of a sudden, your WebObjects application server is also a client to some other application server. It may play the role of both the server and a client. And so what WebObjects 4.5 adds is a factoring out of the parts of the request and response that were common.

And so we now have in WebObjects 4.5 introduced into the class hierarchy a "woe" message. And "woe request" and "woe response" are subclasses of "woe message." So when you look at... When you're looking for access to certain things that used to be in a request or response, you might have to look in WoMessage to actually get to access those methods. The good news of all this is that your request and your response can now take on a different role.

They no longer have this predefined notion of "I'm a server, I'm a client." In 4.0, oftentimes you would have to do some socket connections to go out and grab requests. Maybe you were in Objective-C, you used NSString's little "go grab this, get me a string from this URL" or something like that. Now we also have a structure in the mechanics of WebObjects to do HTTP connections.

And so we can actually have that client piece of an HTTP connection in your WebObjects application. So WebObjects 4.5 adds that. So it adds WoMessage, WoRequest, WoResponse, or subclasses of that. also have HTTP connection. To do the encoding and decoding of the XML from the object world to the flat XML text world, we've added WoXMLCoder and WoXMLDecoder.

These are two classes that really try to simplify the in and outbound XML data. And all of those, those two classes are actually built on top of IBM's XML parser. I will make a note that in WebObjects 4.5 to use these classes, you actually have to be using Java as your programming language.

Let's talk now about encoding. When you encode, you go from an object and you want to get out an XML file. And we can actually do that with a single method. So it's encode root object with key that you pass an object and you pass it what XML tag you want associated with that top level root. And what you get back is an XML document.

This, this XML coder, WoW XML coder object can actually do this one method, just kind of it magically works for any of the common types: NSArray, NSDictionary, EnterpriseObjects, String, Number, Date, and maybe a few others. It's in the documentation. I would definitely recommend that you take a look at the XML documentation that's in the WebObjects 4.5.

There's a PDF that describes all of this as I'm going through, just for your reference. So, with this single method you can create these, this XML representation of these objects. If you have a data type that's not supported by that, what you can do is you can write a custom method, it's basically encodeObjects for key, that will your past, You're past the object and your responsibility is to return the XML representation of that object.

One of the things that you can--this is all good and great, okay? I have a bunch of--I have an EO and I just want to get an XML representation of that EO. I just send this--I send this object to this--to the coder, let it go to work. The one thing to be aware of is that by default, it'll take that object, encode it, and then follow all the relationships, all the related objects, and encode them as well. So the downside of this is that as you navigate relationships, it goes to the next object. So you have, let's say you have an employee.

You archive the, it codes the employee. It then goes to the department, codes it, but then there's an inverse relationship going back to employees, so then it codes all of the employees for that department. So you can imagine that in a well-connected object model, everything, your entire database gets encoded. Not exactly what you want in most situations.

So, ways of avoiding this. One is, on your EO, you can actually implement the custom encoder method and say which attributes and which relationships to actually encode and not. You can also use a mapping file, which I'm going to show in just a second. Or the other way is to actually, if it's possible, you can actually turn off the class property of the inverse relationships. If it's not a class property, it doesn't actually follow it to encode. So let's take a look at this method.

The top one is kind of the single, don't do any work, throw in an object, and get an XML document out. And it's basically you create a coder and you send it the encode root object for key message. And the bottom one is using a mapping file. You basically create a coder with the mapping file and then send that same message.

So what does a mapping file look like? Using XML we describe the mapping file and it's, this is actually the same one I showed earlier today. What it says is what your entity name is and it says the tag, XML tag to use and which attributes of that to actually encode with some flags to deal with special cases. Now decoding. Again, single method, you can actually decode your object into your, you can decode your XML into an object. So you have this XML file and you want an object from it.

With the single method, what you generally get back is either an array or a dictionary or an array of dictionaries. And we're going to show this in the demo a little later. You can also use a mapping file. to specify how that encoding or decoding, how that decoding actually happens. From the encoding standpoint, you're typically going to do that, use a mapping file in order to adhere to a certain DTD. And decoding, you're going to use that to basically map the XML someone's giving you into your objects, your enterprise objects, and the attributes that are there.

Unless you've convinced the other person to use the exact same names that you are using in your EOs. Just as a side note for decoding and kind of, excuse me, parsing the documents, you also have access, the IBM parser is there, so you can use the SACS API to deal with that.

And the response object, you can actually, if it's an XML document, you can actually ask it, give me a DOM document from this, from the request, from the response content. So, in this HTTP connection kind of thing, you get a document back, if it's XML, you can just ask that response object, give me that thing as a DOM document and manipulate it with that API.

An example of this is Related Links, which goes out and uses the Netscape Related Links service on the web. You give it a website and it comes back with all the related sites to that. It's all done using mapping files, so you can get a sense for that. And it's a really good example of kind of all the little ins and outs and different ways of using the encoder and decoder.

One pitfall to avoid when you're decoding, occasionally the decoder will look and if you have four, say, three things that have name, so you have three tags right after each other that are name or The first thing you'll see is a string that is a single string back.

So what you'll get is an array of three strings. Well, if there's only one, what you're going to get is basically a single string back instead of an array of one size. So there's a forced list option in the mapping file that will always make it an array, even if there's only one.

So I've seen that bite a few customers. So now let's go on to kind of uses of XML. And the one we're going to focus on here is really server-to-server communication. Used often for data interchange and transferring and communicating between two applications. Going from the previous discussion, you might actually use XML in this mechanism to exchange snapshots, even if someone thinks that's a flurry of activity. But that's an example of some kind of thing you might use.

You also might use this for remote method invocation. There are a number of protocols out there, XMLRPC, SOAP is another one that's gaining wide acceptance. Electronic data interchange is another example of server-to-server just completing a purchase order or something like that. Content management is generally a popular use for XML and dealing with putting content from one place to another. There are a number of people actually using this today. With WebObjects, there's a company down in Florida, NetCommerce Corp, using all sorts of XML for content management. There are a number of others that I'm sure are here today doing similar kinds of things.

Content syndication, this is what we're going to talk about in just a second. I have an article. I'm a publisher. I'm an author, a site that has a bunch of authors creating content. And I want to sell that or push that out to a number of different sites. And these sites want to get kind of the top headline news.

So if I'm Reuters and I want all the, I want to sell my content out, we might use content syndication to push that out or have them poll for that information. And so there are a number of standards. All the, most of these are all based on XML. The bottom line is there are kind of two flows. You either push the content to the subscriber or the subscriber periodically polls for new content.

So in the push model, a new article goes in and it gets pushed out to the servers and they're just sitting there waiting to accept it. In the poll scenario, the subscriber periodically asks for requests. Do you have new articles? And the publisher pushes out those new articles when asked. This is actually the model that we're going to use for our little simple demonstration of putting this in action.

So, what I would like to do is bring Michael Leong on stage. So, what we've done here is, before we started, we created a direct web application. Direct web is not a toy. We created a simple direct web application here, and what we're going to do is add syndication to this. This is going to be our publisher. So, I use direct web because I can add an article very simply. So, what we did was create a simple direct action class and called syndication.

And we're going to add a few methods to create this XML document on request. So the first thing we want to do, as kind of a general good coding, a good programming style, we want to create one coder object. So one Woe XML coder. And we're going to save that as an IVAR on the top.

And we've got a bunch of code in the middle that goes out and, given a certain client ID, ID will fetch the articles that they have not seen yet.

The next thing we want to do is call that one method: encode root object for key, passing in the array of articles and giving it a key. In this case the key we're going to give it is articles.

The next thing that we want to do is create a wo response. So we are going to be the vendor of this XML document. And so we're going to create a wo response that we're going to append this XML document to. So we create our new wo response. And the first thing we're going to do is create the, add into that response the XML kind of identifier for the actual document itself. So we see the less than question mark XML version kind of thing here.

This is a hard one to remember. We actually can just copy and paste this. Just to make sure we get it right. So we now have the response. We've added kind of this XML initial part. And now we're going to go ahead and append that content to the response.

This is our XML string we did with the one line in code root object for key. And finally, what we want to do is set the MIME type so that the receiver of this will actually get the, understand it as an XML document, as opposed to trying to interpret it as an HTML document.

and finally see that we return the response. So what we're going to do is go ahead and build this. And assuming we haven't made any typos, compile, and we're going to go ahead and run it. and if we could switch to machine four, machine five, sorry. So if we bring up our browser now, what I'm going to do is access that site, that application, as if I'm a content subscriber, a syndication subscriber.

So this is pretending I'm looking for all the XML, the XML version of the article listing of all the messages. So I have that bookmarked here. What we get now is produced by that Direct Web Application with that little Direct Action Class add-in, we now have an array of articles.

In this case, three articles. You see our XML version up here. And each article has So, what we're going to do is we're going to take a look at the web object applications inside it, publish date, the text, and you'll notice that it also has references to, in this case, because we encoded EOs, it has relationships, in this case, to one.

So, on the, when we get to the building the server, sorry, the syndication client, the subscriber, because we have two WebObjects applications, we're going to take advantage of that, and what we're actually going to get is EO generic records back on the other side. So we'll be able to do all of our key value coding very easily.

So we have that. Now what we want to do is build, so if we switch back to machine four, now what we want to do is build that syndication Client and add the decoding. So take this XML string that we just saw and make objects out of it.

What does that take? And so what we have is, we have a little application that's really just designed to kind of show news articles. And again, the first thing we want to do is create an IVAR for the decoder, just kind of have that around and reuse it. Creating a decoder or an encoder is a little bit of a heavyweight operation. We don't want to do that for every single request.

And now what we want to do is create, use that WebObjects as a client functionality that's been added, and create a WoW HTTP connection object. And what this takes is a host and a port number. And then we're going to go through the process of sending a request over the line.

So where we can start chanting faster, faster, faster. So now what we're going to do is take that HTTP connection that we have and we're actually going to send a request through that connection. And the request we send is actually going to be a WoeRequest object. So again, you get to use the same classes you've been using before, the difference is you're using them in the opposite manner that you have been accustomed to. In this case, we actually create Will requests and get back Will responses. As opposed to the traditional role of getting requests and making responses.

And after we send that request, what we want to do is actually, we have the request, now what we want to do is pull the response out of that connection request. So we're going to read the response into a response object. And again, do that lazy initialization. Since we haven't, we want to make sure we actually have a decoder already, and if we don't, we need to create one.

So at this point, we have the XML document in a woe request, a woe response. And we have a decoder, so now we get to call that one method, decodeRootObject, and decodeRootObject, given this NSData, will give us our objects back. In this particular case, what we're getting back every time is an array, an array of articles. It may be an empty array if there were no new articles, but we're always going to get back an array.

So we decode it. And we have these new articles now. What we want to do is simply add these articles to So, the very first time we run the application, it goes out and fetches all the articles, and then every other time it requests them, if there are new ones, we'll simply add that to the list of available articles we have.

Now, there are a whole bunch of, we made this very simple, we simplified the problem, and in fact, we're going to ask for new articles on every request that comes into the application. We're doing this pretty much entirely from a demo perspective, because having a timer sitting there, you know, we sit even longer than we have been watching, waiting for Michael to type faster. Faster, faster, faster. Okay, so we're done. So, we're going to go ahead and run this application. So, it's built, and we're going to run it now.

and what we're going to do at this point is bring up So, we're going to split the screen, so for the overflow room I apologize if it gets a little difficult to follow. What we're going to have is on the screen to my left, your right, we're going to have the servers, and we're going to have both servers running there, and on the other screen we're going to have the browser. So, if you want to switch so we have both of them looking.

Okay, so what I'm going to do is simply access this site. So what we have here is the three articles. So when we did that, when I first accessed it, it went across to the subscriber, asked the publisher, give me your articles, and if you can highlight, Michael, the XML.

Sorry, I got ahead of myself. We're not logging at this point. What I'm going to do now is, well we got those three articles back. I asked for all the messages. There are currently three messages in the system. So what we're going to do now is add a message to the system. So I'm going to go back to the, I'm going to go to the direct web version of the application. This is the publisher now. And I'm just going to create a new article.

So I'm going to create a new article and say,

Okay, and the publication date for this one, we're going to make it May, what's today's date? 18th? May 18th, 2000. And this has to do with airports and I'm the author here. So I'll go ahead and I'm going to save it.

It's going to go into the database, but no syndication will happen immediately. Alright, so that article is saved. Now, what I'm going to do is I'm just going to click on a link here. Any link will cause a request to the application, which is going to cause, like I said, every request that comes into the news site, So what we'll see is when I click on this, we'll see the two send the XML messages back and forth and then it'll be added to this page here. So when I click on this, it goes across and what we see at the bottom, what we see at the top is the actual XML that got created. Again, that eogeneric record and at the bottom you see that we inserted one new article.

So we've used the client capabilities in our WebObjects application, HTTP connection, to send requests out, get back XML content, and turn them into objects that are rendered in our webpages. And on the publisher side, we've gone to the database, taken our EOs, and encoded them in XML and sent them out, in this case, based on a direct action. Clearly, there's lots of stuff.

Clearly there's lots of stuff you'd want to, you know, you'd want a polling mechanism, you know, to do it on a timer, you'd want security between all this, but these were really to highlight those APIs that you're going to want to be familiar with to do these things. So thank you Michael, and Michael will be back for a Q&A in a little bit. What I want to do now is switch back to the slides, and that's using WoW XML Coder and WoW XML Decoder to do that XML.

But there is another way, and it may be, so how many people have actually used WoW XML Coder or Decoder out there? A couple. Alright, so how many people have done XML with WebObjects basically using the component model? Just building a component and generating XML? Okay, we have a couple. So a whole lot of hands went up earlier that they were doing WebObjects and XML stuff. I'm missing something. What else have you used? Object space DXML? Okay. So you've just taken your objects and created XML using other libraries.

Okay, so using other things to create your XML. Okay, well, besides the WoW XML coder and decoder, you can use the component model. The component model basically says, to date we've been using, Components as part of pages to generate HTML documents. These documents happen to be tagged. So why can't we just make these documents of an XML type? And the answer is you can easily do that, and we're going to have a demo of an example of that coming up real soon. But WebObjects itself actually uses this method.

My understanding, just to make sure I'm right, is the Direct-to-Java client actually uses this to create those XMLs, part of the XML that goes out to the Java client application. There are components that are generating this XML. So you can actually use WebObjects Builder to put XML, do the repetitions, simply inserting the tags using Woe Generic Container, Woe Generic Element. Or you can also use a new class, a new component that was added in 4.5, I believe, called Woe XML Node. It's in the Woe Extensions Framework.

And it really is probably the easiest way to learn. Just, you want to create an XML document, you can create in Builder, connect up some generic elements, generic containers, bind them to things, and you should be able to create XML very quickly without understanding,

So what I'll do now is bring on Ron Lusang, who you saw earlier today doing SMILE. He was really focusing there on the client side, using SMILE to make QuickTime your browser, or not use your browser, and have QuickTime be your UI.

What Ron's going to talk about now is how he did that using Generic Element, Generic Container, and WoW XML there. Thanks, Ron. Ron Lusang: Okay, so how many of you were here for the session earlier this morning? Whoa, hello. Okay, so did you guys like that? Yeah. Ron Lusang: Okay. Thank you.

So now you're probably wondering though, so exactly how did I build the framework? What does it really look like? Okay. Here's the source for the framework. I've got a whole bunch of Woe components and they pretty much map directly to all of the elements that are in the SMILE spec. Each of the elements like the document, the media objects, everything, has its own component.

And I even have a sort of an inheritance model here that all inherits from Smile Element. Simple thing. As Tim had said, you want to remember though to set the MIME type. What I do in my framework though is for the SMILE document, I actually set the MIME type for application SMILE, since this is SMILE specifically versus generic XML.

Each of these elements has a couple of things in them. The main, the very important one, the one that you guys all saw this morning, is the smile media object. I've got some logic in here for actually generating the source and the href tag, the href attribute that goes along with the tag.

A whole lot of other

All of these, though, are generated from Web components, and most of them only contain... Most of them only contain this. This is all that I did. I've got component content so that you can nest things, and then the actual media object that So, by doing this, you can lay them out in WAB the way you would lay out HTML elements that you normally would.

So, to see an example of that, here's the application that I showed earlier and the video page. This is actually what it looks like. Beautiful smile elements that you can bind all of your logic to. You can set the MIME type for any of the media that you're sending out for the SMILE media objects. So one thing with all of these will components WebObjects really wants to know what bindings are going to be in there beforehand. So that's why I have all these very, this very long list of variables in some of my objects.

Now, what if you've got some things that you don't really know ahead of time? In my framework, I don't really know ahead of time what you people who would build applications using this would use as attributes in your smile tags. I left one thing in here. A other tag string.

This lets me add random things to any of the tags that get generated for my smile documents. In my application here, there are some extensions to smile that were added by QuickTime. A QuickTime player can understand a couple more tags, and one of them is the Qt autoplay, Qt time slider, and the Qt next values. If I can run this on a different port real quick.

So, we've got... So we can go and take a look at the actual source here. Let's choose... actually, why don't we Sherlock for it? Let's do that. That's another thing. So, Sherlock. Okay. Use of XML here. Still will components on my app side. I've described what my application is going to send back to Sherlock once it's found something, how it's going to be formatted, how all the results are formatted. It's formatted

We'll take a look at all the songs in my app. So we'll try lock songs.

Now I've got a direct action in my app that will give me pop rock music.

Oh, no wonder. Seems to be something using my OpenBase connection. Alright. The main thing I wanted to show you though is what it looks like once we've actually generated all of the, once we've bound all of the tags to values in our logic. It looks basically like this, except all the WebObjects tags are changed.

You've seen this before. It looks just like your HTML would. That's kind of the beauty of it, right? You can still use Wob to generate something that isn't really what you're used to generating with WebObjects. Instead of HTML, you're generating XML. You can use stuff beyond just component content and WoE components. You can use the WoE XML node.

My framework for generating I've got a subproject here called Search Me. This is what the tags look like in here. You can see here I've got WoW XML node. And the cool thing, so I've mixed WoW XML node with WoW repetitions, WoW strings, and WoW links, WoW hyperlink.

This is another advantage. So instead of having to go through and concentrate on using the mapping coder and generating all of the extra stuff that you would need to talk to Sherlock or to QuickTime, you just build it in Wob and it all kind of just works. It's kind of the nice thing about it. I suggest that everyone try this out. It's a beautiful thing.

Thanks, Ron. So you have two opportunities. You can use WoXML Coder/Decoder. If you're going to be vending and consuming and trying to go both directions, perhaps it's worth learning that. If you just want to be vending XML out to other sites or other users or other applications, then the component model makes a lot of sense because it's a really natural fit for what you've probably been doing with generating HTML applications.

So WebObjects and XML, in summary, it can be both a vendor and a consumer of XML. We've added facilities to deal with the client side of an HTTP connection, as well as both consuming and vending the XML itself. Easy encoding and decoding, encoding component model or WoXML Coder, decoding WoXML Decoder, as well as other APIs. Mapping files if you need DTD adherence both in and out. And it's actually used within the WebObjects application, WebObjects product itself in a number of different ways, Direct to Java Client being just one of them.

And it is used today by the number of hands, by a number of developers out there already. So I encourage you to go and start to create XML stuff and vend it to the world. So with that, I'd like to bring Michael and Ron back up to answer any questions. And Ernie, any questions that you might have about XML WebObjects? So a big hand for Tim and the gang.