View Full Version : XML/XSL backwards compatiblility
Hey there, at work we've got a project where we will be using XML to store all the data for a massive system - using XSLT too output HTML.
The clients want it to be as accecssible as possible (i.e. so it works on CE, netscape 4, ie 4 and screen readers).
They want it to run locally as well as off a server.
My original idea was to "compile" the XML/XSL and serve the clients HTML files, updating them when necessary from a server. However, they want the XML/XSL to be local in some cases.
So what ideas do you have as to how to get as many browsers/systems to works as possible in this scenario?
<font face='Courier New'><font color=maroon>»» Dan (dan@pupius.net)
»» www.pupius.net || [url="http://www.dhtmlcentral.com/resources/redirect.asp?linkid=23"]www.endoflow.com[/url:s7z42updc8] || www.13thparallel.org</font id=maroon></font id='Courier New'>
Well, unless the clients have a XSL parser and a web server on their local they won't be able to use the XSL/XML, using all browsers.
If you are talking Microsoft only you can use the Microsoft XML DOM that is built in to 5.5 and higher. I have a pretty usable code for that if you want.
But I wouldn't recommend it. Why? Well Microsoft as usual is trying to manipulate everything to their will and you cannot use every piece of function that <xsl:----> has to offer. Plus some tags are completely different.
The best suggestion is to tell your business people they don't know enough to know what they want.
<label>
<xsl:attribute name="value">
<xsl:value-of select="person/name/Cahal"/>
</xsl:attribute>
</label>
Yeah, we realise this. It's something that's in the client tender and is causeing some problems.
Just looking for some innovative alternatives - for example a Java Applet that does the trasnformation...
Not a nice solution but it is a possibility.
(ie5.5's XSLT parser is aweful)
<font face='Courier New'><font color=maroon>»» Dan (dan@pupius.net)
»» www.pupius.net || [url="http://www.dhtmlcentral.com/resources/redirect.asp?linkid=23"]www.endoflow.com[/url:o965768os1] || www.13thparallel.org</font id=maroon></font id='Courier New'>
Edited by - dan on 08 March 2002 15:07:59
Brian Nickel
08.03.2002, 14:05
An applet would be the best choice, but you would have the downside of a non-caching web site.
A thing you could do is as well as use the applet for rendering, use it for decompression, as in gziping your files. (Based off of wranlon's site.) That way, it will also load quicker and you get 2 birds with one stone.
<font face='Courier New'><font color=brown>.Brian
It is best to remain silent and be thought a fool than to open your mouth and remove all doubt.</font id=brown></font id='Courier New'>
Yeah, but in this case it'd be on a local machine so it'd be fast anyway. There isn't a problem with requests that are made to the server.
They want a version of the (web based) software so they can run it from a CD for example.
<font face='Courier New'><font color=maroon>»» Dan (dan@pupius.net)
»» www.pupius.net || [url="http://www.dhtmlcentral.com/resources/redirect.asp?linkid=23"]www.endoflow.com[/url:kc6ix43f6k] || www.13thparallel.org</font id=maroon></font id='Courier New'>
<BLOCKQUOTE id=quote><font size=1 face="Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Yeah, but in this case it'd be on a local machine so it'd be fast anyway. There isn't a problem with requests that are made to the server.
They want a version of the (web based) software so they can run it from a CD for example.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Arial, Helvetica" size=2 id=quote>
??? Sounds crazier than my project.
I've heard flash handles XML... I don't know if it parses or how exactly how it handles the XML since I've not checked it out. (not a big fan of FLASH)
The only way out (that I would use) is to skip the XHTML mark-up and going directly to "insert your coding language here" based application.
Java I find handles XML pretty well
<label>
<xsl:attribute name="value">
<xsl:value-of select="person/name/Cahal"/>
</xsl:attribute>
</label>
I've tried the applet approach for XML/XSL transforms, and the hardest problems I ran into were getting the parsers actually loaded, and getting the XML data to the applet. Also, I had a horrible time with all the different browser versions' support of the various JREs. My Mozilla would never auto install and I always have to manually copy the binaries to the plugin directory. Plus, only certain JRE versions work with Mozilla. All things considered, it wasn't too hard to make. But, on the user end, it was pretty scary and frustrating getting it setup and waiting for the applet to load the supporting libraries.
Or, you could just include a mini Java server instead of an applet that would serve up regular HTML content, and do live transforms as needed.
Stephen W. Cote
wranlon@hotmail.com
http://www.whitefrost.com/
uh ... great :)
Hopefully we can make it so we in effect compile the HTML on a server... That way we can create documents that will work in everything from screen readers to Web TV.
<font face='Courier New'><font color=maroon>»» Dan (dan@pupius.net)
»» www.pupius.net || [url="http://www.dhtmlcentral.com/resources/redirect.asp?linkid=23"]www.endoflow.com[/url:4uk0dicfxi] || www.13thparallel.org</font id=maroon></font id='Courier New'>
russcoon
09.03.2002, 01:46
Sounds like someone needs a flexible caching engine =)
I wrote something like that which cached different versions of output from the same input resource in Python in like half a day. Sounds like your main problem is figuring out what to cache and what not to. In that case, if there's anywhere in your middle or front-end layer of the project where you can flag a resource as "cachable" or not, then that's the way to go. Generate output in chunks and cache those chunks and not necessarialy the final product. Should scale well enough.
And yeah, you really should figure out whether or not your client _really_ needs to support every device on the planet.
--
Alex Russell
http://netWindows.org
http://alex.netWindows.org
Accessibility it the main consideration as it's a learning product - therefore screen readers are *deffinitely* part of the spec and probably the lowest denominator as far as compatibility goes.
The real question is does the client really need to have the XML/XSL performed locally - we say not, but it's their brief...
<font face='Courier New'><font color=maroon>»» Dan (dan@pupius.net)
»» www.pupius.net || [url="http://www.dhtmlcentral.com/resources/redirect.asp?linkid=23"]www.endoflow.com[/url:pn0x25tnw4] || www.13thparallel.org</font id=maroon></font id='Courier New'>
vBulletin® v3.6.7, Copyright ©2000-2008, Jelsoft Enterprises Ltd.