XSLT Rendering for Website - Stage 1 Of Many

**XSLT Guru needed **We want to re-skin our website. We have the exact HTML we need to generate (from our graphic designer) and the exact XML from our existing website business layer. What we need is the XSLT that can transform the provided XML into the provided HTML. (We will supply an example case of each, input and output, that we designed to be something of a test case.) We will then integrate that XSLT back into our existing website. This is the first of many similar projects, because its the first of a few pages that we are redesigning. If this goes well there will be a handful of immediate follow up projects - approximately the same size range, though we expect later projects to be technically harder. (There is also other work further down the road too) Basically the current site is really ugly and hard to use. The presentation layer of the site is in XSLT with JSP to tie things together. We have a fully functional site, and new deisgns. We want to swap out the presentation XSLT of the existing site for new XSLT that you will write, so as to create the new look. **About Us** AutismWell provides personalised recommendations on treatment options to parents of autistic children. It is a non-profit but well funded project using the underlying technology of a previous dot com venture called Medigenesis.com. We have 2 years of funding from a corporate foundation taking us into March 2010. Currently we are working on revamping the presentation layer of the Medigenesis site and hope to launch the new site to a limited audience in mid June. I am a programmer by trade and the technical architect of the original site. I hope that providing exact desired output and exact input example we can work to define this work as clearly and specifically as possible so you can get on with it. ## Deliverables This is basically a specification by example. The minimum requirement is that you provide XSLT that can render the supplied HTML using only the supplied XML file(s). That is basically the test case. It will be pretty clear from the exampe provided that what we need to do is provide something that is able to take *general* XML of the type provided and produce the desired HTML in the general case. For this to work you need to perform work in the spirit of the task. Hardcoding of any actual output values, to produce only the example HTML no matter what the provided XML is very clearly cheating (to someone skilled in the art) and not the functionality we need. It should be pretty clear to anyone skilled in the art of programming when this 'hard coding' is being done - this would not be in the spirit of what we need and will not be accepted as complete work.. I would like to clarify a few points about exact rendering details as we do this job, these will in the vast majority of the cases not add to the complexity of the task but only clarify it, so in that case its probably best to deal with these things as they come up. There may be one or two cases where I want to do something in a more general way than you think is necessary. All I can promise is that I will try to be reasonable here, and not make your work unduly difficult. If you do the abs minimum required to fulfil the objectives I will be reasonable about this and you will be sure to get paid, however if you are a little bit flexible - shall we say *up to* about 10% more difficult than the minimum case - then I will be more happy and this will lead to more work down the line. Remember I have worked as a programmer myself for years - so I know exactly what scope creep is, and I will absolutely not be doing that. We can agree that there will be no deviation from the provided HTML in terms of desired functionality for the provided test case XML. ----- I could go on for hours and hours explaining exactly where in the XML you need to look for the values in the desired HTML, however it is probably best just to look very closely at the example, and perhaps reference the old xslt stylesheets that I am also including. I am available for any questions on these points though,a nd would expacct that you would have a few questions. ------------------ UPDATE ----------------- Based on a question I had, the XML on its own is not clear enough. I will try to post more information about the XML in coming days, but for now let me just add a couple of clarifications. Yes, the XML supplied ([login to view URL]) is supposed to correspond exactly to that which will be produced for the supplied HTML. It is definitely the XML that was used to produce the example output from the old system* [ * It was taken directly from that system with one small exception being that that I hacked it to add a few more severity history rows, but these are the same as if they were produced by the live system. ] The XML is not the easiest to read I'll readily admit - but unfortunately that is exactly* what we get out of business layer of our existing system. For the information you need to do this job, please have a look under the node 'eventList' - basically everything you need will be underneath that node. Also pay a lot of attention to the formalProblem child of each event. Basically a 'formalProblem' is a symptom and an 'event' is a diagnosis that this person has that symptom. That is, when a person 'has' a formalProblem that fact is is called an 'event' in the XML. For instance, the headings for the presentation of the data break out into different sections come from the 'eventType' field of the FormalProblems. Also of great importance are the attributes that end in capital "I" on the formalProblem. These indicate whether that particular field is relevant for that particular problem. locationI="1", indicates that this formalProblem can have a location (for instance hives can appear in your foot, groin, leg, arm etc etc) modifierI="1", indicates that this formalProblem allows a 'modifier'. A modifier can either be 'left', 'right' or 'bilateral'. For instance if I have short sightedness only in my left eye then my event for 'myopia' would have its modifier set to "left". In our current mockup we just lump left/right/bilateral into the same category as Location, visually. episodicDurationI="1", indicates that this formalProblem is something that can have a duration for each episdoe.. for instance hiccups can occur for 'minutes to hours' each time it occurs frequencyI="1", indicates that this formalProblem is something that allows a frequency for instance hiccups can have a frequency set to occurs 'occasionally'. (Whereas for instance "Vegetarian" doesn't allow a frequency so its FrequencyI is set to 0.) onsetI="1", indicates that this formalProlbem is something that has an onset date. For instance the 'fever' had an onset of Jan 22. Onset Dates can also be something more vague like started in.. 'My Twenties'. untilI="1", is similar in format to the above, this indicates that this type of formalProblem allows an end date. For example the earache ended 'in childhood'. When an event has no endedWhen date set, it is said to be 'ongoing'. Events with an endedWhen date appear in the 'Past Events' section only (This takes precedence over other sorting rules). "College" is an example of something which doesn't allow a start/end date severityHistoryI="1" , severityI="1" these will either be set to both true or both false. If something allows severity and severtyHistory it allows that it can have an onsetSeverity set - this can be set to one of four values only 'mild', 'moderate', 'severe' or 'variable'. If it has a severityHistory set to true it allows the user to record severity history for that event, where each severityHistory row has a date (a 'normal' date) and a severity from 1-12 per the HTML of the mockup. -- Excepting for the values for the severityHistory drop down, the dictionaries of allowed values for the above fields appears in the [login to view URL] file. As i say below, you can edit this file to add/remove information that the XSLT may also need. -- All of this is a bit verbose, yes, and maybe a little 'illogical' in places - but that is the XML we have to work with and we want to do this whole project without having to edit the 'business layer' where the XML is produced... ---- ** There is a 'married' event that appears in the input XML but not the output HTML. This is because it is an event of type "Personal Information". and events of this type do not appear on this screen. However perhaps that was a stupid thing to do - if you like I can remove that from the spec - and consider it either removed from the input xml or add it to the output html. ----- The following is the text of the [login to view URL] from the attached zip file. ------------- [login to view URL] ------------- This is just a screen shot of what the page we want to end up looking like. ------------- desired_output/[login to view URL] ------------- This contains the HTML we want you to generate from the supplied XML input. Actually we don't need you to generate *all* the HTML in this file, only the HTML between the <!--- START HERE ----> and <!--- END HERE ---> tags. (Which is most of it). A minimum requirement is that your XSLT should produce *exactly* this output from the provided input. Whitespace and trivial formatting differences are OK, but easiest to aim for EXACTLY this output. (You may want to set this up as a JUNit test case during development). As stated in the description, if you want to write a test harness, and provide it to us, along with the XSLT, that would be good - we would like that - but let us know if thats what you want to do, so we can bear that in mind for your proposal. ------------- input/[login to view URL] ------------- This is the input file that you may need to use as input to your stylesheet to produce the desired output.html. This is a dump of the exact XML from our site as it currently exists. If you need small changes to this we can make them, subject to it being a very small trivial change for us. If you need us to pass in parameters to the XSLT - such as todays date or something - that is also possible, subject to it being trivial to do. ------------- input/[login to view URL] ------------- This is helpful to give you an idea of the kind of variation that you will need to support in terms of varying values for various key input parameters. It is also potentially useful for providing values for drop downs and such. If you want you can edit this file to suit your needs. This is actually a copy of the file "old_site_for_reference_only/existing_xslt/[login to view URL]" and as such really belongs more in the XSLT folder. Thats why you can edit it, becuase its not strictly 'input'. However I placed it in this directory so as to draw attention to the values within. As I say we want to support the general case where input values vary according to the dictionary(s) of values supplied in this file. ------------- output_in_context ------------- Since prouducing pure HTML with no colors or stylesheets could be demoralizing we are also providing the context files that go aroud the desired HtML output. Generally speaking if you place the produced output into the output_in_context\medical directory, you should see a page in your browser that looks like the attached screen shot. ------------- old_site_for_reference_only/[login to view URL] ------------- I'm supplying the [login to view URL] just so you can get a quick idea of how the page works in terms of how it calls the XSLT engine. The [login to view URL] page won't even come close to working as it stands because it depends on the total infrastrcture of the site, which I am trying to avoid you having to worry about. (so don't try to do that it woudl be a waste of time. write your own XSLT rendering test harness). ------------- old_site_for_reference_only/[login to view URL] ------------- I'm providing the [login to view URL] just to give you an idea how the old site used to look - this is pretty much useless to you though. Remember we are *not* trying to generate this. ------------- old_site_for_reference_only/existing_xslt ------------- You can use (by copy and paste) any of the code, or reference any of the xslt files from the existing_xslt folder. If you use any of that code, thats fine, but please copy only the files that you use, plus the ones that you create into a seperate folder, so we can tell what its what. If you want to modify these files please create a new filename, and remove the code you don't use - again so we know whats what. As you can see the existing XSLT was somewhat modular, so it would be a good idea to stay quite modular in the way you do things going forward. If you do this in a modular way it will make future projects that you do with us, for other pages on the site both easier for you to do, and more likely that you will be the one doing them ;_) ------------- old_site_for_reference_only/existing_libs ------------- As I said in the job description we currently use an older version of the XSLT rendering library XALAN. If you are able to get everything working whilst staying at this version of the library that would be, by far the easiest for us. However I would understand if you want to update to use the latest version of hte XSLT spec. That is understandable. If so please just specify what libraries you are using and make sure these are available for our use, preferably via LGPL or similar, but we are willing to contemplate a small licensing fee for a library if you let us know up front. It has to be something that can run under java 1.3 VM though. (Specifically the site currently runs /usr/lib/j2sdk1.3-ibm/bin/java - so, the IBM 1.3 Java VM on Debian Linux). -----