HTML vs XML

[Tannin]

These days it is cool to have your site coded in XHTML instead of HTML.

OK, I'm cool with that, but why? The other week I spent a couple of hours reading stuff at various sites about the differences and why XHTML is such a fantastic idea and all the rest of it, and the down-to-earth, practical, here-and-now advantages added up to:

The disadvantages, on the other hand, were many. The two that stick in my mind are:

• All sorts of buggerising around with server configurations because so many web browsers don't actually understand it yet. (Details now forgotten.)
• A complete black ban on HTML entities such as — to make $#8212; major[/] inconvenience factor, lots and lots of wasted time.
  

So, am I missing something? Or is XHTML (for the ordinary web coder like me without any particular special needs) a complete waste of time and effort?

(All of my sites are currently in valid HTML 4 strict.) (Well, valid last time I checked.)

 

[Tannin]

Errr .... let's try that again:

the down-to-earth, practical, here-and-now advantages added up to:

• ...

The disadvantages, on the other hand, were many. The two that stick in my mind are:

• All sorts of buggerising around with server configurations because so many web browsers don't actually understand it yet. (Details now forgotten.)
• A complete black ban on HTML entities such as — to make — major inconvenience factor, lots and lots of wasted time.

(Why says Tea is the only one who doesn't proof-read her posts?)

 

[LiamC]

If the site/content is (relatively) static, I'd agree with you.

If your site has mostly dynamic content--changing data read from a db--then XHTML makes a lot of sense. The caveats here are you are using a application server that builds the content on the fly and then passes the data stream to a web server to serve to the client.

At work I code just such a beast that deals with archived data. But the application itself is a JSP/Servlet application. Where XHTML would shine is in the user interface. At the moment, the java code is littered with HTML constructs to output user messages. As this was hard/time consumming for the original developers, there is a lot of stack trace dumps when writing all the mis-mash code got to them. If everything in the app was XML, the underlying code would be a lot simpler and a lot neater. To render the final output--be it the user requested data, error message, screen, help or guidance would just be a transform on the data stream. Code monkeys wouldn't have to worry about formatting. The business wants to go with new corporate look/logo/feel. Sure. Write a bunch of style sheets (XSLT and/or CSS--they can be complimentary) and you're good to go. By change here, I mean changing the format of the actual data presented, not just the presentation. CSS can do a lot, but XSLT on XML can do more.

 

[Will Rickards]

The benefit (or disadvantage) of XHTML is it is based on XML so well formed structure is a requirment. Rather than having to correct HTML that is not well formed, browsers are free to just throw up their hands and say this isn't valid XHTML. For a developer this means you find those bugs faster rather than a browser correcting it for you.

But IE doesn't understand XHTML served as anything other than text/html. And still 90% or so use IE.
So the choice is:
A) just write HTML and make sure all your tag names and stuff are lowercase and well formed so xhtml transition is easier later.
b) write XHTML and serve it as text/html.

What your store your data for dynamic pages in is another matter entirely. XSL is nice but the learning curve steep. It can output html or xhtml or plain text or pdf.

 

[Handruin]

HTML or XHTML, very enlightening and yet controversial subject.

 

[Tannin]

Hmmm ... a very interesting point of view in that article you linked to Doug. In a nutshell, it boils down to three points:

1: HTML is a crappy and bastardised sort of language with a lot of limitations and is (in the author's opinion) dead in the water.

2: XHTML in its present form is completely different in that ... er ... well ... it is going to be different one day. Really. Trust me on this. But at the moment, the practical, real-world advantages of XHTML are ... um ... well there aren't any.

3: But code in XHTML 1.0 anyway because then you will be cool.

I don't buy it. I think I'll switch when there is actually a practical advantage to doing so. In the meantime, I'll continue to code in clean, valid, well-formed* HTML 4 Strict.




* Except for when I say "bugger it" and throw some quick and horrible hack together, of course.

 

[Tannin]

... just write HTML and make sure all your tag names and stuff are lowercase and well formed so xhtml transition is easier later.

Yup. That's the path I'm following, Will. Looks like I should stick to it, at least for now. If I ever need the sort of stuff Bill posted about (which I might before too long), then the transition should not be too painful.

 

[LiamC]

If I ever need the sort of stuff Bill posted about (which I might before too long), then the transition should not be too painful.

You (shortly) have a need to access 11 terabytes of data!?? Man, your bandwidth costs must be terrible!

Seriously, the reason our app is as it is is because we have to access such a large volume of data. I luv going to IBM presentations where they talk about the scalability and access times of DB2 when they have large tables-- 2 or three million rows! I pipe up and say "buddy, when you start talking 300, 400 million rows, a billion rows, get back to me". Shuts them up real quick. Amatuers!

Everything is XML, so XHTML makes a lot of sense.

Those are the current numbers and I'm just about add another table with 3, 400 million rows, of 100KB (avg) PDF's & a growth rate of 90M py.

And all of this is only a tiny fraction of the total data holdings. :eekers:

Our medium term forward planning is into the petabytes.

 

[mubs]

So, William, which database do you guys use to handle those gargantuan tables? AFAIK, there are only two gorillas out there, DB2 and Orcale. Sybase has been a has-been for far too long now.

 

[LiamC]

Oh its DB2, I was just trying to highlight how marketers/trainers can be a little removed from the real world. And in the trainers case, some of their solutions look good for small tables, but don't scale that well

 

[Mercutio]

This really has nothing much to do with XML but...

I have need to access around 11TB of data (actually about 6.5TB, but you know, gotta build in some redundant storage and expansion capability).
At present I use a variety of proprietary tools (Escient for CD/DVD catalog, homebrew LAMP for video files, but nothing but a well maintained directory structure for pictures or audio files, let alone all the other crap I have) and have no single point for cataloging or querying everything I have.

I'd KILL for a network-transparent filesystem with a defineable metadata schema; something so that I could stop paying attention to which machine I'm copying things to, and also implemented definable keywords on save to make searching a worthwhile endevor.

I use a combination of NFS and dfs to minimize my fussing with where things are stored, but that doesn't solve the metadata problem. And on the day when that problem IS solved, I'm going to have weeks and maybe months of work properly categorizing everything.

Microsoft is supposed to be adding WinFS to address some of these concerns, but I'm wondering... can any of the "big boy" database tools handle that sort of thing NOW?

 

[LiamC]

Offhand, I'd say Teradata. Not really my sphere, but give me a few days and I know a few people I can ask.

 

[mubs]

Teradata...Be prepared to lay out some serious cash. Things don't get any more "industrial-strength" than that.