Need Help with simple XML web site

I was asked to put together a brochure type 5 page web site in XML. They want it done in XML because each page uses a few dynamic fields such as company name, company logo, phone and e-mail. This web site will be hosted on clients server so I do not have any control over middle tier programming and so this is a purely client side XML web site.

I have put something together with my limited knowledge of XML, but it doesn't parse on Mac and older browsers.
I need a solution asap I this up as 500 point question, but if done fast and with expected result I will add a couple hundred more, I do not expect anyone to build the whole web site for me but given above, I need xml, xsl and a schema that works on majority of browsers starting with IE 5 and NS 6

Older browsers are not necessarily XML-capable. XML is a much more recent standard than HTML, and just because a client has a browser doesn't mean it is going to be able to parse XML. In fact, I don't believe that IE5 supports true standards-compliant XML. (It supported a MS-bastardized version, and you won't get that version to work on other browsers.)

You could use server-side scripting to turn your XML into HTML before sending it to the client. Can you use any server-side scripting?

Frankly, if you don't have access to some form of server-side scripting or something similar, and you have to support older browsers, what the client has asked for just can't be done. The closest you might be able to do would be to provide the client with a script that would produce HTML files to be uploaded onto the website. Then, the client would run the script to produce a different version of the HTML for every different site he needs.

Since you have used an inline style, I'm guessing you are working with CSS-capable browsers. I would strongly advise that you start using CSS for more of your formatting, instead of such attributes as leftmargin, topmargin, marginheight, marginwidth, cellpadding, cellspacing, width and border. If you want to use XML and XSL to produce HTML, you should generally be producing HTML compliant with the XHTML standard, and none of those properties are in the XHTML standard. It really is easier to do away with them.

Ok, I'll be honest and tell you that I was hoping that there is a universal solution that would run on IE 5+ since I am not doing anything complicated, but I usually try to produce a site that is compatible with IE 5.5 and Netscape 6.1. about those atributes such as topmargin, marginheight, marginwidth, cellpadding, they don't have to be there, that HTML was just an example of how I would use the XML data.

Server side programming is out of the picture, I belive that if the client had that ability, they would not ask for XML, because really what they are using it for, is not the most efficient way to go.

Even with IE 5.5, I think you might have trouble. I know that MSXML3 comes with IE 6, but I think IE 5.5 only gives the client MSXML1, and MSXML1 is a very long way short of standards-compliance. I'll check my docs when I'm back at work tomorrow, but I seem to recall that this is one of the reasons why I told my bosses to stop mucking around with IE5 and incorporate IE6 into our standard PC build. (Which shouldn't be hard at all because we are supposed to only be rolling out Windows XP these days, but somehow we still end up with IE5 floating around the place.)

NS 6 might support something reasonably close to standard XML/XSL. I'm not sure about that one at all.

Thanks travisjhall,
at this point I am not concerned so much for standard compliance as I am with browser compatibility. There are way to many IE 5.5 around for me to ignore them. Mac OS X, comes with an IE ver. 5.1 which is not the same as PC version of IE 5.0, but more closer to 5.5.

You're not going to get browser compatibility. It doesn't exist. That's why there aren't many XML pages-- you have no way of knowing what the user will see. Whether they see anything at all is even iffy.

XML needs to be transformed on the server (at least right now). If you can't do that, I suggest you forget XML entirely, and go with a HTML/javascript solution. The data they need to change could be in a .js file, which they could keep, edit, and reupload when needed.

Works for everybody (if you set it up right), doesn't need server side support, and is easy to maintain.

webwoman,
so you're telling me that it's NOT possible to create a XML website that will work on both PC and MAC browsers simultaneously?

Yet I have seen XML websites and they do work on both OSs even under IE 5.

Again I am not asking for crazzy XML to be used just the very basic features, which would be supported by the early browsers that have any XML/XSL support. If you look at my example I have 5 nodes that just need to be plugged into various places on the page.

Well, according to the article that you mention, IE 5 and 5.5 apparently have usable XML support. I haven't found them particularly good for this, but my difficulties may have resulted more from poor CSS support than poor XML support. All I know is, the differences between the two were significant enough that I found that I basically had to write two versions of half my pages to support them both. (Noting that what I had to do involved some pretty tricky layout and scripting. Actually, part of my problem was that 5.0 wouldn't handle page breaks properly when printing - that was a killer for a very important system.)

Webwoman's right, though. There are a lot of browsers out there, and XML support is very patchy. You may well be able to put together an XML-based website that will work on some PC browsers and some Mac browsers, but you certainly can't support all the browsers in common use today.

And while I realise you may not be that concerned with standards-compliance, but the fact is that standards-compliance is often a gateway to cross-platform support. When you've got a whole bunch of browsers with different, incompatible XML implementations, you've got to decide which implementations you can support. Generally, sticking to standards and avoiding the various extensions to the standards gets you working at a basic level at least on a wider variety of browsers.

Frankly, I wouldn't attempt implementing an XML website for the internet. Your client's expectations of this technology are foolishly high, and he's going to be disappointed somehow. XML is great when you are working in a controlled environment (like where I work, where I can tell people to upgrade to the corporation's minimum standards before they expect stuff to work), but the internet is very much not controlled.

What XML websites have you seen that work for everybody? Please provide links. And remember that everybody means NN4+, AOL, etc.

Remember, they have to have XML extensions -- not something that has an XML dataset that gets transformed on the server.

I've tried to use the examples on tutorial sites, and even THOSE don't work in all browsers. Heck, they don't even work in different versions of IE! It's not just the browser, it's the XML it supports, and you can NEVER be sure of that. You could even have two computers, same OS, same browser, same VERSION, but one has the latest patch and one doesn't. On one, your XML works. On the other, it doesn't.

As was mentioned, if you have complete and total control over the browser being used, you can make it work - MAYBE. But on a regular internet site? No way in Hades it's going to work.

I believe he said he needed IE 5 and NS 6 or higher, not NN4, AOL or other old obscure browsers...but I can't imagine anyone really uses NS 6...And don't email me saying "Oh, I use it *exclusively* and it's the best browser ever built", because I won't believe you! ;^)

As far as the XML support goes, if you allow IE 5, IE 5.1, IE 5.5, IE 6 and Netscape 7.1, Moz and other Gecko based browsers that provide XML/XSLT support, you should be able to cover it. Mac support is tricky. For the PC, you need to ensure MSXML 3 is installed in the case of IE 5, 5.1 or 5.5. This can be done with a little javascript and an object tag.

In response to TravisJhill's assertion: "It supported a MS-bastardized version", I'd point out that it was based on the current working draft at the time, which was in turn based on the original submission to the W3C in August 1997 (http://www.w3.org/TR/NOTE-XSL) (which in turn was based on DSSSL), and the first working draft came out a year later in August 1998. Obviously the final rec changed, but to call MSXML 2's implementation a bastardization is to defy the fact that 1997 comes before 1998 which comes before 1999, which comes before 2000 when Microsoft released MSXML 3. At the time, EVERYBODY knew that implementations of XSLT were based on a "snapshot" of the working draft, and the developer's sense of where it all was going. That's life for early implementers.

Frankly, if client-side dynamic data is a strict requirement, Webwoman's suggestion of using javascript files with the dynamic data is the best one, and the one I'd use if I was trying to support the greatest number of browsers. But then, it won't work on browsers with javascript disabled...

I wasn't talking about MSXML2's implementation. Version 1.0 of MSXML did not conform to anything that I've heard of being called a standard. That's the version that just handles Microsoft's "data islands". I haven't encountered version 2 at all, so I don't think it comes as a standard part of any version of IE, though I might be wrong. Versions 3 and 4 of MSXML aren't too bad (though some releases had really dodgy install packages). Actually, I'm very happy with how well they have been working where I work, on our intranet. The only problem is, MSXML 3.0 and 4.0 do not come installed with IE5, so unless your IE5 users have actually gone to the trouble to install the XML support specially, you are still stuck.

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Well, MSXML 1 is *really* ancient. It didn't conform to any "standard" because it predates virtually all of them. In fact, if I'm not mistaken, it was released even before XML itself was a standard. We're talking IE 4 here. IE 5 and 5.5 came with versions of MSXML 2. As for being out of luck using IE 5 with MSXML 3 or 4, that's not the case at all:

on the page to pop up a dialog that has the object tag to install MSXML 3 or 4.

But then, I wouldn't really consider client side XML and XSLT for broad internet distribution of a brochure-ware site. Server-side, yes, definitely. For sites where you can impose browser restrictions, client-side is fine.

Thanks fot all your input and suggestions, but it doesn't look like there is a way to accomplish what I have set out to do. Although the answers are great they are not what I was looking for and I am not quite ready to award 500 points for them.

is a reasonable approach for dynamically writing content client-side, with fairly reasonable confidence that it would work across all platforms (except those who have disabled javascript).

On the other hand (and this is stated in http://www.experts-exchange.com/Community_Support/help.jsp#hi89), sometimes "You can't do that" is a correct answer. In this particular case, if using XML *and* working client-side across all platforms/browsers are both requirements, then I would say, it's not worth the effort to make it work. It's hard enough, though certainly possible, to using client-side XML/XSLT in IE 5+ and NS 7.1. But to add all other "modern" browsers makes the solution enough of a least common denominator that it's not worth the effort.

MSDN article Q246073 lists the files distributed with IE5.01. One of those files is msxml.dll, which is MSXML 1 (msxml2.dll is MSXML 2, msxml3.dll is MSXML 3), and IE5.01 was a 1999 release. Msxml2.dll is not in the list. MSXML 1 had very little in common with the XML standard, which was finalised in 1999. (Earlier in 1999 than the IE 5.01 release, I think, because IE 5.01 was pretty late in the year.) MSXML 2 may have been around then, but it wasn't installed with IE 5.01.

You could attempt an install of MSXML3 on client machines (if the user chooses to allow it), but I wouldn't imagine that would be a particularly fast install. It certainly wouldn't work cross-platform, as only Windows uses ActiveX (at least as standard). You could possibly make cover all the browsers in some fashion, as rdcpro says, but as he also says, this is likely to be far more work than it is worth. You really would be better off just using some javascript - it'll be easier for you, cheaper for the client, and require less of the customer machines.

As for closing the question, I think I agree with rdcpro. The best answer that exists is that what you're trying to do won't work. You've been given a fair bit of useful information, and each of us has gone to some effort to try to help you. It's not our fault that what you are attempting won't work, and I don't think it's really on to withdraw the points for a question when you've been given good answers, just because you don't like the implications of the answers.

As for me personally, I'd rather not get the points than be given points and a poor grade, which is a mechanism that could be employed against an expert who simply pushes for points. I'd advise giving the points to webwoman, who really gave the best approach to getting around the actual problem.

Just to set the record straight, I can understand your confusion, because MS did some silly things with version numbering. When you see msxml.dll, it could be version 1 or version 2. The DLL was named the same.

msxml2.dll was actually the January web release version of MSXML 2.6, which was the first version to support the XSLT recommendation. But msxml2.dll was not released with any version of IE, though it *was* shipped with Biztalk. IE 5.01 and 5.5 were released with MSXML version 2.5, which was still the old API.

With version 2.6 (msxml2.dll) The ProgID changed also to MSXM2.DomDocument. So, in this case the "2" refers not to the dll version, but the API version, as in the ProgID. Later, when MSXML 3 was released, the ProgID didn't change, but the dll now because msxml3.dll.

They also did a bunch of silliness with "replace mode" and "Side by Side" mode, which was a nightmare to manage. With MSXML 3, SP1 and later, it always installs in replace mode. It's all very confusing, but then it was also all very new, and I can't remember when Microsoft ever had such a rapid development cycle as in the early days of XML.

If you're talking about the version that came with IE5, it's MSXML 2.0. Look at the file version info in that QB article, it will show you. I have a list of all the versions of MSXML and what products they shipped with right here:

All,
If you look at the original question that I posted, I was looking for a solution, NOT a reason why this will not work, all though everyone who participated in this discussion has made a lot of good points, none of which have led me closer to the working solution. I don't want to seem ungrateful for your assistance but this thread is not worth 500 points to me.

Interesting, then, that out of 5 previously asked questions, only one was PAQ'd. Two others were deleted, and if you have your way, two more as well. That will make four out of five questions deleted...

Of course you do -- they ran a diagnostic, you took up their time, they'll charge you.

If your mechanic doesn't charge you to run a diagnostic and spend 2 hrs trying to figure out what the problem is, I want to know why he isn't out of business. ;-) And who/where he is, so I can go there before he DOES go out of business.

But a better analogy is, you take your car to the mechanic, telling him it needs a new battery. He says, no, the alternator is bad. You say, I don't want a new alternator, I want a new battery. He says, well, I can charge the battery, but it won't fix the problem. You say, I don't care about the problem, I just want a new battery. He gives you the phone number of a nearby auto supply store...and an invoice for his work.

Whatever. You don't have to accept an answer, you can always beg CS to delete this question. (Don't forget the one in the XML TA as well). What's more, I won't even object. But then, we don't have to help you with your next question either.

As I said earlier I don't mind awarding some points for this thread, but I left this discussion with just about the same knowledge as before I asked the question. Thus I don't think your "solution" is worth anything close to 500 points. But to be fair I'll let the moderator make the desision as to how many points to award and to whom.

Yeah, I object to that. I don't think I really contributed much towards a solution, or at least not much that webwoman hadn't already covered. I'd rather forego my share and let her have more points. It's fairer. Split it between webwoman and rdcpro.

0

Featured Post

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

"In order to have an organized way for empathy mapping, we rely on a psychological model and trying to model it in a simple way, so we will split the board to three section for each persona and a scenario and try to see what those personas would Do,…

Any person in technology especially those working for big companies should at least know about the basics of web accessibility. Believe it or not there are even laws in place that require businesses to provide such means for the disabled and aging p…