XmlInterchange |
Edit this page |
Wheat must be able to express all content (data, programs, presentation) as XML.
XML ensures that any data that gets put into a Wheat system can one day be extracted in a useful format. Whereas ASCII has served this role for decades, XML allows the same level of "I'm sure I'll be able to parse it", but with fully structured content.
We want XML to be to Wheat what strings are to Awk/Perl/PHP. Wheat needs to make reading, parsing, and writing XML as easy as Perl makes parsing strings, if not easier. The Wheat programmer should spend less time coding the import and export of data and more time coding processing and presentation.
To a degree, it is reasonable to design Wheat's ObjectModel with this in mind.
Some examples of the kind of XML formats that should be handled: need more here
There is now a design for this form: See XmlObjects.
External XML formats are often described by a XmlDescriptionSystem such as DTD, XML Schema or Relax NG. The transformation may take into account such machine readable descriptions if available. In any event, the transformation rules should be designed taking these the facilities available in these systems into account.
Current XML libraries all follow one of two models: Parse the XML and call a set of application supplied call back routines (this is the model of Expat and SAX). Or, read the entire XML into memory and construct a tree to return to the application. These models aren't conducive to making XML pervasive: The first requires far too much work on the part of the application writer. The second isn't practical for larger content, and still requires work.
--MarkLentczner
It's a bit worse than that. If you look at XSLT, you'll see that there is the notion of attributes, elements (children) including text (CDATA), comments, and processing instructions. The text of a node is actually a child, but generally people (and XSLT translators) don't think of it that way. Comments and processing instructions are also potentially special children of the node, and may or may not be considered to be a real part of that node.
--TimLearmont
It is clear to me that CDATA can be incorporated into the scheme as some sort of degenerate node (I like the sound of that: "degenerate node"!) What to do about comments and processing instructions is a bit harder. Clearly any XML utilities will have allow Wheat programs to handle them. But, does the object model need to reflect them? Put another way: If there is some facility for automatic reflection between XML and Wheat objects, does that facility have to support comments and processing instructions?
--MarkLentczner 2003-03-10
References:
XML ensures that any data that gets put into a Wheat system can one day be extracted in a useful format. Whereas ASCII has served this role for decades, XML allows the same level of "I'm sure I'll be able to parse it", but with fully structured content.
We want XML to be to Wheat what strings are to Awk/Perl/PHP. Wheat needs to make reading, parsing, and writing XML as easy as Perl makes parsing strings, if not easier. The Wheat programmer should spend less time coding the import and export of data and more time coding processing and presentation.
Usage Models
There are three usage models for how Wheat programs use XML:1. Wheat object storage
Wheat objects are exported as XML to be transmitted or stored in other systems. At a later time the XML is imported to recreate the Wheat objects (though possibly at a different location). The Wheat server uses this model itself when it stores objects in the host OS's file system, and when transmitting objects over some protocols.
In this mode, all features of the Wheat object model must be preserved round trip to XML and back. The isomorphism with XML should be clear and predictable. It should endeavor to represent Wheat objects naturally in XML so that the objects could be used by other XML systems.
It shouldn't be a sequence of <property> elements with <name> and <value> elements. That is just a cop-out. --MarkLentczner 2003-03-15
To a degree, it is reasonable to design Wheat's ObjectModel with this in mind.
2. External data
Data from other systems that are rendered in XML are read in and rendered as Wheat objects. Wheat objects are convertable to external XML formats. The rendering should be natural and predictable. It should be easy to design Wheat objects that are tailored for ouput into external XML formats.Some examples of the kind of XML formats that should be handled: need more here
- RSS∞ - used for syndicating web news feeds and blogs
- GPX: the GPS eXchange Format∞ - used by geocachers∞
- the XML format for BLOG upload need reference
- flight information in XML is there such a thing? reference?
There is now a design for this form: See XmlObjects.
External XML formats are often described by a XmlDescriptionSystem such as DTD, XML Schema or Relax NG. The transformation may take into account such machine readable descriptions if available. In any event, the transformation rules should be designed taking these the facilities available in these systems into account.
3. XML Manipulation
XML documents, in all their glory, are processed by Wheat programs. This would be a reflection of the DOM as Wheat objects. In this mode, every aspect of the XML document is available for both reading and writing.Current XML libraries all follow one of two models: Parse the XML and call a set of application supplied call back routines (this is the model of Expat and SAX). Or, read the entire XML into memory and construct a tree to return to the application. These models aren't conducive to making XML pervasive: The first requires far too much work on the part of the application writer. The second isn't practical for larger content, and still requires work.
Discussion
I'm not sure I like the notion of attribute being different than children. But there it is in XML. Should Wheat objects have both attributes and contents? XML attributes are limited in what they can have as values: strings. Though, a schema can put some interpretation on that. I believe they can be links, numbers or booleans as well.--MarkLentczner
It's a bit worse than that. If you look at XSLT, you'll see that there is the notion of attributes, elements (children) including text (CDATA), comments, and processing instructions. The text of a node is actually a child, but generally people (and XSLT translators) don't think of it that way. Comments and processing instructions are also potentially special children of the node, and may or may not be considered to be a real part of that node.
--TimLearmont
It is clear to me that CDATA can be incorporated into the scheme as some sort of degenerate node (I like the sound of that: "degenerate node"!) What to do about comments and processing instructions is a bit harder. Clearly any XML utilities will have allow Wheat programs to handle them. But, does the object model need to reflect them? Put another way: If there is some facility for automatic reflection between XML and Wheat objects, does that facility have to support comments and processing instructions?
--MarkLentczner 2003-03-10
References:
XML∞
The Expat XML Parser∞
SAX: the Simple API for XML∞ - written by Mark's old college buddy, Dave Brownell
The Expat XML Parser∞
SAX: the Simple API for XML∞ - written by Mark's old college buddy, Dave Brownell
There is no comment on this page.
[Display comments/form]
