[thelist] Discussing XHTML and ROI with your "boss"

[Tom Dell'Aringa]

--- Judah McAuley <judah at wiredotter.com> wrote:
>
> I'm sorry, but your post really made you come off sounding like an
> ass.
>   People *were* trying to help you and you blew them off rather
> nastily.

I surely wasn't trying to be nasty, and in fact I was answering what
seemed to be, at least to me, some rather ridiculous statements. I'm
not sure how much help they were really trying to be.

> To quote from that webmasterworld thread, someone quoted a W3C
> note:
>
> "Modularizing XHTML provides a means for product designers to
> specify<snip>
>
> That is a business case.  Obviously you didn't read the thread.

Actually, I did read that. It's somewhat helpful, so I suppose I
stand somewhat corrected as to that link.

> To
> go
> even beyond what the W3C mentioned, I'd argue the following:
>
> XHTML is not only a subset of SGML (like HTML), it is a
> syntactically
> valid XML document.  This means that you can do all sorts of things
> with
> is, like use alternate stylesheets and XSLT to transform it to
> match the
> display characteristics of different browsers (read: cell phones,
> pda's,
> search engine spiders).  That seperation of content and display
> opens up
> all sorts of forward-looking display opportunities.  XML-oriented
> structures are also more friendly to manipulation by programming
> languages with nice, happy RegEx expressions.

Ok, thats great - I know all that (above). But in today's market, and
for many businesses - having their web sites or applications
available on Joe Technoweenies phone/PDA are so FAR down their list
its near invisible.

On the other hand, if you can tell me how I can take that XML and
perform other business processes on it that will enable my business
to do things I can't do now -- not THAT is something. Some of those
things are going to be industry/instance specific, but I bet some
things aren't..  those are the types of things I was hoping to flush
out.

For example: Maybe I can take a personnel page on an intranet and
re-use the content on the public facing site. That might be one
example.


> Furthermore, use of current W3C standards ensures future
> compatibility.

I've read this a million times. Ensures future compatibility WITH
WHAT?

>   Standardization is becoming more and more common amongst browser
> agents.  The best way to future-proof your applications is to code
> to
> established standards.

I'd argue the point. IE is still placing their proprietary code in
thier browser, and they still hold the vast majority of the audience.
Even their implementations of "standards" differ among the most
modern browsers.

And what are "established" standards anyway? Which set are you
referring to? HTML4? XHTML1.0 or 1.1? Which DTD? Using tables or not?

And, its difficult to make the case for "future proofing". Tell me
how my application is going to break in say, 5 years. I don't think
you can.

> I'd argue that future-proofed applications, platform independence,
> and
> the ability to multi-purpose content are all solid business cases.
> And
> all of those sort of arguments were included in links sent to you
> in
> previous threads.

Isn't the WEB itself platform independence? It sure is, thats not an
issue. Do you mean BROWSER independence? My site already works in
modern browsers, (all) using HTML only. Why do I need to change?

Multi purposing content is a good idea, but we already do that
because we pull much of our data from DBs.

The arguments made in those threads are the same general things you
are saying now, but nothing SPECIFIC. No real case data.

> Hopefully this will help you in your current predicament.
>
> And yes, stereotypes often do work in the real world.  People have
> a
> tendency to fall into certain positions because they are that sort
> of
> person.  No, it doesn't always apply and I don't think that most
> people
> will say that people are *always* this way or that.  But structures
> and
> hierarchies have a tendency to reinforce themselves.  So don't jump
> on
> people for projecting a common behavior type into a position that
> frequently displays that behavior but doesn't happen to in your
> position.

I'll respectfully disagree. I try to never treat people based on any
stereotype. I certainly wouldn't want to be treated in such a way. If
you walk into a situation with a preconceived notion, you've put
YOURSELF at a disadvantage right away, when the person prooves you
*wrong.*

I've had numerous "bosses" in the same position for many companies,
and NONE of them were the same.

DON'T Mistake my "negativity" for me being against standards or
XHTML. I am 100% FOR them. That's why I am in the position with
MACCAWS that I am.

But I am challenging folks to come up with good, solid reasons, data,
cases and paths to ROI on why they should be used. We are researching
that now at MACCAWS.

I know there are people on this list who have some of this in their
heads (and some of it has come out). So lets not get all upset
because somebody challenges you to come up with more detail, or
challenges you to really explain and quantify something you believe
in.

I'll give you a real world example: Lycos Europe has taken some of
their work to XHTML/CSS. It doesn't quite validate all the way, but
its great code, and the author has shared with us some valuable real
world data on what it saved them, timewise, what the code did for
them and so on.

That's what I am looking for, that type of information, whether
specific or not.

Tom







=====
var me = tom.pixelmech.webDeveloper();

http://www.pixelmech.com/
http://www.maccaws.com/
[Making A Commercial Case for Adopting Web Standards]

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com