A set of command-line XML applications ported to RISC OS, with associated libaries and headers. These applications are based on
The documentation and licences associated with these applications is also included.
The package provides the following (command-line application) binaries:
Or, to put it another way, what on earth is this stuff good for? The problem is that XML on its own really does very little. Its just a standardized way of describing structured data and text. However, the eXstensible Stylesheet Language (XSL) offers a generic mechanism for transforming XML into either some other form of XML, HTML or plain text. Thus, these two standards potentially allow one to seperate a document's content from its presentation, as opposed to HTML where style and content are closely interleaved.
I originally intended to do exactly this for my own website, but totally seperating the style and content did not turn out to be practical. Instead I use an extended XHTML format, with a few extra tags in the source to indicate where the page headers and footers and so on should go. In this way I can define the overall look and (table-based) formatting of my entire website in one place, and apply the same style to every page.
Another potentially more interesting possiblity is to use either a Sablotron port or Justin Fletcher's xsltproc port to add Mozilla-style XML+XSLT browsing to a native RISC OS browser. There are a few complications, in that some mechanism must be added to the code so that the required stylesheets can be downloaded on demand, but apart from that that it should be straightforward to add this capability to any browser. The only real drawback is that such UNIX ports are quite large (for example sabcmd is an 800Kb executable) and require fairly large amount of memory to run (1-2Mb).
The RISC OS version of these applications is down to me, Andy Jackson. I will be glad to hear about any problems with these utilities, but I'm only really responsible for the RISC OS port of these applications. However, any bug reports concerning the original code will be passed back to the original authors who I am in contact with. Aside from any buggynesses, I would love to hear from anyone out there who actually finds this stuff useful! Finally, I'd like to thank Justin Fletcher for his constructive comments and for sending me the 'official' XML filetype icons.
If you would like to contact me about this release, the email address is xmlutils@anjackson.org.
Looking at JF's port of libxml, adding basic throwback chould be do-able. I have throwback.c/h, which will provide the local support, and situa.cc contains the relavent messaging bit (fprint, on line 316). Getting the line numbers and source filenames out of the code will require some work, but its all possible. I'll have to check that its okay for me to use the throwback code.
These applications have been compiled using the hard-mofo GCC under RISC OS, as the code uses C++ templates and cannot be compiled under Norcroft C++. The GCC port does not currently generate 32-bit compilant code, and so these applications can only run on 26-bit mode supporting processors. Note: I had to use gcc 2.95.2 and UnixLib 3.8r2 (the latter so that it can be called reliably from a perl script).
[I believe this problem only relates to v0.51 of sabcmd, not the current version. However, I have not had a chance to test this yet.]
When xsl-ing some example files with sabcmd, this happened:
RiscPC:*sabcmd portfolio.xsl portfolio.xml > portfolio.html Warning [code:455] [URI:file:/raFS::WWW/$/xml/examples/portfolio.xsl] namespace URI 'http://www.w3.org/TR/WD-xsl' bound to 'xsl' is not the current XSLT URI Error [code:2] [URI:file:/raFS::WWW/$/xml/examples/portfolio.xml] [line:1] XML parser error 18: unknown encoding RiscPC:*
Most importantly, it cannot deal with encoding="ISO8859-1" in the xml. Secondly it thinks the namespace is wrong, but I don't believe it is. There may be a better, more recent version of expat, (e.g. the mozilla one) which could cope better.
Also, for each xsl file, I had to replace
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/TR/WD-xsl">
with
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="html" doctype-public="-//W3C//DTD HTML 4.0 Translational//EN"/>
for it to do anything. The simple/xml example was a bit different, but I still had to go from
<HTML xmlns:xsl="http://www.w3.org/TR/WD-xsl">
to
<HTML xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
for it to work. Otherwise, it just spewed out the stylesheet.
In Sabalot.engine.cc.base:
const char *theXSLTNamespace = "http://www.w3.org/1999/XSL/Transform", *oldXSLTNamespace = "http://www.w3.org/XSL/Transform/1.0", *theXMLNamespace = "http://www.w3.org/XML/1998/namespace";
This is used in parser.cc. I think the encoding problem will probably go back to expat... Yes, it does. Probably best to try tweaking the compile options, as well as checking out the Mozilla distribution version.
There are four built-in encodings in expat:
* UTF-8
* UTF-16
* ISO-8859-1 (it don't cope with ISO8859-1 tho')
* US-ASCII
Anything else discovered in an encoding declaration or in the protocol encoding specified in the parser constructor, triggers a call to the UnknownEncodingHandler. This handler gets passed the encoding name and a pointer to an XML_Encoding data structure. Your handler must fill in this structure and return 1 if it knows how to deal with the encoding. Otherwise the handler should return 0. The handler also gets passed a pointer to an optional application data structure that you may indicate when you set the handler.
It really should not be so picky. If you use anything but what it thinks is the true namespace, then the output is screwed. It should warn, but still do it anyway. I think.
The warning mechanism is handled by a generic situation handler (situa.cc/h). That is the only thing called, so why does it go wrong? I'll stick to the old form for now, and perlit when I've sorted it out.
[This refers to a beta frontend to sabcmd which is not included in this distribution.]
The FrontEnd version does not get the output filename and filetype right. Again, this can easily be fixed by wrapping the sabcmd app. Sabcmd expects URI style command-line arguments, and so I'll have to edit the source or write a wrapper-app in order to turn one into the other. The pre-saved options will work, but it is not sufficently general for the app to be any real. AND, you can't access the command-line options at the moment.