Something resembling a final report

... has been put here:

http://xmldad.googlecode.com/svn/files/Report/

I sent out an email about this too. Just take a look and possibly mark down any ideas you have..

XSL Client implmentation

I have uploaded two example XML documents using stylesheets to provide a GUI. Notes:

- While these are able to draw a GUI fine, when submitting I need a way to convert the form variables into an XML document to submit to the server (since the server accepts XML instances), this is difficult to do client side and easier with a server in Java (still it means duplication of efforts if the server is expecting XML instances). With this in mind an HTML client is perhaps not suitable for a client-server architecture communicating with XML instances.

- The server needs to read either the form variables (and process to XML) or read an XML instance, then redirect the client by issuing it with the appropriate XML document, e.g. sending the client a "searchResults.xml" document after the client issues a "search.xml" document (or form values) to the server.

- The stylesheets are hard coded into any XML instance so that the client knows which stylesheet to use for which instance.

Just open up any of the XML documents in a web browser to see how they display...

Also:
- I used Nathans XSD documents from svn
- I put these into /trunk/xslclient...
- Download all files in /xslclient to a folder on your PC before opening the XML documents (the paths to the stylesheets are relative and wont work if you open them from the webserver).

Update:
- I just added "submit.xml" which is meant to submit a new book to the server. Effectively this is the same as "search.xml" but has the server do something different with the XML instance.

- I just realised that the sending of XML (as opposed to form variables) is part of what AJAX does ... so yeh a client done in HTML is viable and can be finished by implementing AJAX to send the XML instances.

I have been thinking about the RDB generation. If the architecture is only semi-dynamic then its fairly easy to write some code that translates MySQL results to XML and vice-versa. Now obviously this would break if the XSD changed but its not that complicated so is fairly easy to maintain. The following article shows how this can be done:

http://www.kitebird.com/articles/mysql-xml.html

Its in PHP but shows how some simple scripts can convert to/from XML. When writing it assumptions would have to be made (e.g. you expect the "title" element as the first child element of "book" - but even this assumes more than necessary). We can just think about how the XSD we have maps to a RDB table and then look for certain complex types or patters to determine which table they belong to. It’s not nice but it is quick and easy – we can add complexity later if time permits.

Also if we don’t need a fully dynamic architecture then the MySQL schema can be created by us, it doesn’t need to be generated from an XML Schema. I will try and define an XML Schema for requests and responses and then define the database structure, just to get things kicked off.

SOAP / REST

Its worth taking a look at this:

http://www.w3schools.com/soap/soap_intro.asp

I think SOAP meets our needs nicely and if the API's in .Net and Java are good then we should use this over REST.

A SOAP message is entirely XML, has really good support for error messages (http://www.w3schools.com/soap/soap_fault.asp), supports headers for info relating to the message, supports optional/required headers, and lots of other stuff we dont need.

It will be fairly straight forward to take some XML content and insert it into the body of a SOAP request.

Some other rules I stole from w3schools:

• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing Instructions

Links

Something someone might find interesting:

Dingo:

• http://dingo.sourceforge.net/faq.shtml
• http://dingo.sourceforge.net/foobar_sample.shtml
• http://dingo.sourceforge.net/geneology_sample.shtml
• http://dingo.sourceforge.net/contact_sample.shtml

Castor:

• http://www.geocities.com/sireenmalik/details.html
• http://www.drrockit.com/space/castorcodeexample

REST:

• http://www.networkworld.com/ee/2003/eerest.html
• http://www.manageability.org/blog/stuff/rest-explained-in-code
• http://www.manageability.org/blog/stuff/why-rest-part-2

Documents and binary repository

I have made a folder in the svn repository, /files, for documents and binaries, this is as good place as any to put these sorts of files. I've linked to this from the main project page. The URL is:

http://xmldad.googlecode.com/svn/files/

Oh yeah, also all commits made to svn will email Richard, I tried to add all of us but it only supports one email address. You guys can change it anyway if it doesn't suit, its in administer -> project summary at the bottom.

Issues with Google Code

Regarding Richard's problems with the subversion system I've been investigating this and have got it working using SmartSVN... the settings I used:

SVN Location:https://xmldad.googlecode.com/svn
SVN Path: /svn
Username: abishell
Password: (as it states on the page)

The only issue I can think of is maybe http://xmldad.googlecode.com/svn was used (the anonymous URL - not the https)...

I successfully checked out what was on the server (i.e. nothing) and comitted test.cpp into /trunk.

Current planning stage

After Thursdays meeting its become difficult to determine exactly how the communication which be achieved between client and server, let alone what will actually be communicated (does it even need to be XML).

The main points are:

• Everything is, in some way, based around a book object (presumably defined in an XML Schema document).
• The GUI should be, at least partially, built from the book object.
• The RDBMS should be, at least partially, built from the book object.
• Communication is undecided and will involve the most research, things to consider:
• REST vs SOAP.
• Sending a valid XML document closely related to the book object or using our own syntax for a request.
• Allowing a client to query and/or update the database?
• What can the server return to the client? Search results (how are these orgainised), error messages, etc.
  

More ideas

Again this is a little dated and is just being put here for record keeping. This was the idea that two schemas are build: request.xsd (sent by the client, containing a single book object) and response.xsd (sent by the server, representing search results and referencing multiple book objects from request.xsd).

(Note: Still working out a good way to upload these .xsd files so I can link them here)

Something basic

For record keeping purposes I am posting the first basic prototype of the XML Schema doucments. This was changed last week...

To the left you can see book.xsd, the initial idea was to have a kind of book querying facility supported by the client which sends a semi-populated book.xsd object where the server does substring matching on all appropriate fields.

Test post...

Just a test post to make this is working...