Frontier 5 and XML: The Plan
We're doing a lot of work with XML with Frontier 5. As we make progress or move in new directions, I'll update this page.
12/26/97 at 10:51:26 AM by DW
Hand-coding XML
XML is as strongly hierarchic as HTML. It should be easy to come up with an outline renderer that produces XML content. Also, the newCulture renderer works really well with XML. It spits out nicely indented code. You don't go blind looking for the hierarchy. So we already have a nice authoring environment for hand-coding XML.
There's no doubt that the next generation browsers from Netscape and Microsoft will support an HTML-equivalent language, with the same basic capabilities, that follows XML syntax. We're ready, right now, to generate content for those browsers.
Machine-generated XML
XML will be used as a transport system for objects between databases. In this case, humans never see the XML, it's generated by software, and on the other end, it's turned into database structures, again by software.
No doubt Oracle, Informix, Sybase, Acius, Claris, Microsoft, et al are wiring up their databases to send and receive XML. We're wiring up Frontier to send and receive XML.This gives us a transport method between databases across platforms.
I think we're going to be able to store the most general form of XML. I'm not sure if the relational database guys are going to be limited to a subset of the general XML format. We'll be watching for announcements, and linking to them of course.
XML as an application file format
Microsoft announced that the applications in the Office suite will be storing their files in XML in the next release. That got my interest into super high gear.
We can store and serve objects created by other apps running on other platforms. This is going to be much cleaner and faster than the Apple Event object model we use on the Mac. Send a request for an object to the app, and it sends back the XML code. Then we invisibly turn that into a table structure. You walk the table, get what you want, and then send back the result, using XML, of course.
Another angle, XML is emerging as a strong cross-platform standard, bridging Windows and Unix, and we can bridge from Windows to the Mac. Our support for XML will be 100 percent cross-platform, Mac and Windows.
Historic note
XML is a modern cousin of the dot-head format we used in the 1980s to transport outlines across platforms and between different software products. I've been here before. It's interesting to go around the loop.
Where we're at now
See RPC via HTTP for a report on the work we're doing to connect Frontier up to XML interfaces over the net.
We've written and XML Parser in UserTalk that turns XML text into a structure of tables and strings.
This picture shows a Notepad window containing some text we just received:
The parser runs, and produces a structure of tables and strings:
Observations
Frontier's object database is a good choice for storing XML, but it isn't absolutely perfect. There's a rule that every object at a level has to have a unique name. XML doesn't have this requirement, in fact it's likely that there will be many states, provinces, and countries, as in the example above.
So we "steal" a character from XML, the slash. We may have to change this. Tell me if you think this is nuts. Reading the spec, I thought of using colons, they almost suggest it in the spec. We have to have an escape character.
We've discussed this quite a bit. Another idea surfaced, creating an extra level of hierarchy when there are collisions. Please look at the situation carefully before you suggest a solution. It's not a simple problem.
Where to go from here
I think we have the proof of concept now. Not ready to deploy yet. We have to write code that produces XML from one of these table structures, and write a set of access routines that make it easy to walk one of these structures; and a set of routines to create one.
Once all that is smoothed out, we'll recode the scripts in C and suck them down into the Frontier kernel. This project is on a separate track from Frontier 5. If the code is ready in time for the release of 5, it'll be included, otherwise it will be included in an update.
I really want it to be in the final release because it will give us a strong position in what looks to be a very powerful market.
|
© Copyright 1996-97 UserLand Software. This page was last built on 1/14/98; 2:48:02 PM.
It was originally posted on 12/26/97; 10:48:00 AM.
Webmaster: dave@scripting.com.
|
