This document describes any notes on implementation that will assist the developer in creating a new XML-X implementation for a new language.
For all other information, see the XML-X site.
The Primary Authors of XML-X are Erwin van der Koogh and Ian Grigg. The Author of this document is Ian Grigg. See the site for more details.
Parts in italics are optional at some level, for implementation, client or server.
The following notes are being made as implementations progress, more for recording. They belong in the proper XML-X reference (like an RFC) rather than this introductory guide.
The following is a primer on the rules of XML, in order to lay the foundation upon which XML-X lives. That is, XML-X must still follow XML rules even as it creates its own. (This inconvenience is imposed because most XML-X implementations will use standard XML tools to do the DOM tree.)
To be properly formed, each full request will have an XML header on it:
<xml xmlns="http://xml-x.org/xml" encoding="blah"/>
Unless otherwise indicated, the order of the XML-X tags is important, and processing must preserve the order of tags.
In pure XML Whitespace before and after the tag contents, and between tags, is to be preserved. That is, the content of the following
<Tag>Text</Tag><Gat>Stuff</Gat>
is always different to:
<Tag>
Text
</Tag>
<Gat>
Stuff
</Gat>
XML insists that any higher layers make up their own rules as to canonicalisation, and XML itself must preserve any additional spacing.
The name of each tag and attribute is case dependant. That is, <Auth> is different to <AUTH>, and again, not the same as <aUtH>
The order of attributes cannot be defined in XML.
For attributes, double quotes must be used. For example, the following is legal:
<Request rid="666" version="1"> ... </Request>
whereas the following are not:
<Request rid='666' version=1> ... </Request>
Content of tags must not include special XML characters:
< > & " '
It is the caller's responsibility to encode them, unless it is documented by the tag that these are always encoded and decoded.
In XML-X Whitespace before and after the tag contents, and between tags, is stripped (before and after tags is relevant in XML). That is, the content of the following
<Tag>Text</Tag><Gat>Stuff</Gat>
is generally the same as of:
<Tag>
Text
</Tag>
<Gat>
Stuff
</Gat>
being the words Text and Stuff with no leading or trailing whitespace.
Content of tags in general should only accept the further subsidiary XML-X tags that are documented.
The general case where a tag accepts derivative XML of an unknown type would be <Memo>. In that case, the whitespace conventions of XML must be preserved, in contrast to the above.
In XML-X, all tags are by convention capitalised, that is, the first letter of each word in the name is a capital. E.g., TransferRequest. Tags that are not the right case should be rejected.
In XML-X, all attributes are by convention lowercase. E.g., name="IanG". Attributes that are not the right case should be rejected.
In XML-X, all attributes with a truth value accept only true and false in all lowercase. E.g., negative="true".
For any given implementation, it is the caller's responsibility to encode contents to remove XML special characters, unless it is documented by the tag that these are always encoded and decoded.
How the XML-X packets and requests are delivered between a client and a server is undefined within XML-X. Follows are guideline notes on how it has been done in some implementations.
For the outgoing Request use application content header:
Content-type: x-application/xmlx
within the HTTP headers. The Response returns the same header.
The XML-X packet should be marshalled (dumped to text) and put after the headers (extra blank line). The number of characters sent should be set in the headers. Note that if CR/LF is used as the line ending, both will need to be counted.
For direct delivery, it should be sufficient to open the socket connection, send the request, and wait for the reply.
Reserved...
Reserved...
It would seem that SOAP is now out of favour and REST is in favour. If a document defining how to do REST were to exist on the net, we'd do that. Meanwhile, there is a lot of waffle and not much in the way of actual implementation details...
It may be that the HTTP POST method above is more or less a subset of REST.
The Content-type in REST appears to suggest text/xml.
The leading tag:
may need to be supported.
No discovery has been defined or thought about.
SDP1 implementation is Reserved...
XML-RPC has not been pursued because it hides the value of the XML - a clear instruction and response that exchanges between the two administrative entities. In disputes, the benefit of XML-X is that you can print out the XML and agree on the contents; using something like XML-RPC hides this.
Do we require the standard XML declaration:
<?xml version="1.0" standalone="yes"?>
(As found in GM's spec.) For more information, see http://www.itworld.com/nl/xml_prac/04192001/.