XML Web Site + MySQL

[Mark]

Hi,

I'm developing my website using XML + XSLT. I'd like to insert some
data into my XML from a MySQL database. Typically I would do this
with PHP, but my web server doesn't seem to support PHP in *.xml
documents. Is there another way I could do this?

For example, I would like to do something like

// header data

<blog>

<?php
$result = mysql_query("SELECT * FROM blog");
while($row = mysql_fetch_assoc($result)) {
$title = $row['title'];
$descrip = $row['descrip'];
$article = $row['article'];
echo "
<title>$title</title>
<descrip>$descrip</title>
<article>$article</article>
";
}
?>

</blog>

// footer data

or something that produces the same effect. It would be even nicer if
I could somehow use XSLT to rewrite the XML so that I could have tags
like

<sql:query="SELECT * FROM blog"/>
<sql:for-each-row>
<title><sql:value-of select="title"></title>
....
</sql:for-each-row>

But maybe I'm just dreaming...

 

[Philippe Poulard]

Mark a écrit :

Hi,

I'm developing my website using XML + XSLT. I'd like to insert some
data into my XML from a MySQL database. Typically I would do this
with PHP, but my web server doesn't seem to support PHP in *.xml
documents. Is there another way I could do this?

For example, I would like to do something like

// header data

<blog>

<?php
$result = mysql_query("SELECT * FROM blog");
while($row = mysql_fetch_assoc($result)) {
$title = $row['title'];
$descrip = $row['descrip'];
$article = $row['article'];
echo "
<title>$title</title>
<descrip>$descrip</title>
<article>$article</article>
";
}
?>

</blog>

// footer data

or something that produces the same effect. It would be even nicer if
I could somehow use XSLT to rewrite the XML so that I could have tags
like

<sql:query="SELECT * FROM blog"/>
<sql:for-each-row>
<title><sql:value-of select="title"></title>
...
</sql:for-each-row>

Active Tags can do that.
http://ns.inria.org/active-tags/

If you are an XSLT user, you might be familiar with XPath ; in Active
Tags, most objects behave as XML and are accessible with XPath :
<sql:connect name="mySQLdb" url="..."/>
<sql:select name="blog" connection="{$mySQLdb}" query="SELECT * FROM blog"/>
<xcl:for-each name="row" select="{$blog/*}">
<title>{$row/title}</title>

But maybe I'm just dreaming...

RefleX is the name of the implementation of Active Tags

Have a look here :
http://reflex.gforge.inria.fr/tutorial-fromSqlToMvc.html#sql
and have the RefleX !

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !

 

[Pavel Lepin]

I'm developing my website using XML + XSLT.

I hope you don't mean you serve XML documents with
xml-stylesheet PI's. As a rule of the thumb, that's a bad
idea. Transform server-side and serve HTML 4.01 Strict
instead. The reasons have been discussed half a zillion
times in the past on this newsgroup, as well as on several
others.

I'd like to insert some data into my XML from a MySQL
database. Typically I would do this with PHP, but my web
server doesn't seem to support PHP in *.xml documents.

The PHP is not invoked for those files. If you insist on
doing this, either reconfigure you http server to invoke
PHP for those files, or, if you're unable to do that, force
the invocation (by renaming/moving your files to match the
http server's idea of what PHP should be invoked for).
You'll need to set Content-Type via header() call as well.
Better yet, as I said above, transform server-side. PHP5
has XSL extension which uses libxslt as a transformation
engine.

You could also employ stored procedures to move the burden
of generating XML documents to SQL server. This path is
fraught with peril, though, since you need to ensure
well-formedness.

or something that produces the same effect. It would be
even nicer if I could somehow use XSLT to rewrite the XML
so that I could have tags like

<sql:query="SELECT * FROM blog"/>
<sql:for-each-row>
<title><sql:value-of select="title"></title>
...
</sql:for-each-row>

I don't like the idea. You already use PHP, presumably for
application logic/interfacing with the http server, SQL for
juggling you relational data, and XSLT for presentational
transformations. Now you want to introduce a custom
language with poorly defined domain into the equation. From
my (relatively extensive) experience with custom glues this
is going to have two main consequences:

1) The logic is going to drown in all that glue.
2) As you move forward, you'll realize that you want more
and more features in your language as you need done various
things you hadn't though of at first. This has two possible
outcomes: either you leave your language in this
rudimentary state and delegate the logic to PHP or SQL
anyway, or you slowly move towards Turing-completeness, the
end-result being a slow, poorly designed and frail language
of your own (think early versions of PHP/FI--in fact, the
scenario described is in a way how PHP came to be).

As a matter of fact, tinkering with languages of your own is
a wonderful pastime, but not recommended for Real Work
unless you're extremely sure of your footing.

To answer your specific question, what you want to achieve
is impossible with XSLT alone. It may be possible with
custom extensions for your XSLT processor, but quite a
chore anyway. A saner alternative is implementing a
separate processor for your language (in PHP/whatever), but
even that's a dangerous route to take due to reasons
outlined above.

 

[Mark]

I hope you don't mean you serve XML documents with
xml-stylesheet PI's. As a rule of the thumb, that's a bad
idea. Transform server-side and serve HTML 4.01 Strict
instead. The reasons have been discussed half a zillion
times in the past on this newsgroup, as well as on several
others.


The PHP is not invoked for those files. If you insist on
doing this, either reconfigure you http server to invoke
PHP for those files, or, if you're unable to do that, force
the invocation (by renaming/moving your files to match the
http server's idea of what PHP should be invoked for).
You'll need to set Content-Type via header() call as well.
Better yet, as I said above, transform server-side. PHP5
has XSL extension which uses libxslt as a transformation
engine.

You could also employ stored procedures to move the burden
of generating XML documents to SQL server. This path is
fraught with peril, though, since you need to ensure
well-formedness.



I don't like the idea. You already use PHP, presumably for
application logic/interfacing with the http server, SQL for
juggling you relational data, and XSLT for presentational
transformations. Now you want to introduce a custom
language with poorly defined domain into the equation. From
my (relatively extensive) experience with custom glues this
is going to have two main consequences:

1) The logic is going to drown in all that glue.
2) As you move forward, you'll realize that you want more
and more features in your language as you need done various
things you hadn't though of at first. This has two possible
outcomes: either you leave your language in this
rudimentary state and delegate the logic to PHP or SQL
anyway, or you slowly move towards Turing-completeness, the
end-result being a slow, poorly designed and frail language
of your own (think early versions of PHP/FI--in fact, the
scenario described is in a way how PHP came to be).

As a matter of fact, tinkering with languages of your own is
a wonderful pastime, but not recommended for Real Work
unless you're extremely sure of your footing.

To answer your specific question, what you want to achieve
is impossible with XSLT alone. It may be possible with
custom extensions for your XSLT processor, but quite a
chore anyway. A saner alternative is implementing a
separate processor for your language (in PHP/whatever), but
even that's a dangerous route to take due to reasons
outlined above.

Very informative post. Thank you for taking the time to write that
all out!

If I can get XSLT to do all my dirty work, I may not need PHP at all.
I just need to figure out how to handle forms... then I won't have
such a muddle of technologies.

Yes, I am transforming the XML client-side. Which method do you
recommend for doing it server-side? Could you point me in the right
direction? I understand there are multiple ways to do this...

Reflex/Active Tags sounds like what I was looking for, but it might be
a little tricky to get working on my server. My host doesn't seem to
like me muddling with things (I somehow managed to crash the server
once already!)

I guess my last option is to do it all with PHP. I hope it isn't too
horrible to implement...

 

[Mark]

Mark a écrit :

Hi,

I'm developing my website using XML + XSLT. I'd like to insert some
data into my XML from a MySQL database. Typically I would do this
with PHP, but my web server doesn't seem to support PHP in *.xml
documents. Is there another way I could do this?

For example, I would like to do something like

// header data

<blog>

<?php
$result = mysql_query("SELECT * FROM blog");
while($row = mysql_fetch_assoc($result)) {
$title = $row['title'];
$descrip = $row['descrip'];
$article = $row['article'];
echo "
<title>$title</title>
<descrip>$descrip</title>
<article>$article</article>
";
}
?>

</blog>

// footer data

or something that produces the same effect. It would be even nicer if
I could somehow use XSLT to rewrite the XML so that I could have tags
like

<sql:query="SELECT * FROM blog"/>
<sql:for-each-row>
<title><sql:value-of select="title"></title>
...
</sql:for-each-row>

Active Tags can do that.http://ns.inria.org/active-tags/

If you are an XSLT user, you might be familiar with XPath ; in Active
Tags, most objects behave as XML and are accessible with XPath :
<sql:connect name="mySQLdb" url="..."/>
<sql:select name="blog" connection="{$mySQLdb}" query="SELECT * FROM blog"/>
<xcl:for-each name="row" select="{$blog/*}">
<title>{$row/title}</title>
</xcl:for-each>

But maybe I'm just dreaming...

RefleX is the name of the implementation of Active Tags

Have a look here :http://reflex.gforge.inria.fr/tutorial-fromSqlToMvc.html#sql
and have the RefleX !

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |

This looks neat, but I have no idea how I might get this running on my
server (I don't own the server). Thanks though!

 

[Peter Flynn]

Yes, I am transforming the XML client-side. Which method do you
recommend for doing it server-side? Could you point me in the right
direction? I understand there are multiple ways to do this...

See if your server operator runs Cocoon. That's an XML server which runs
XSLT to serve HTML, PDF, ... and has Java connectors to databases.

///Peter

 

[Johannes Baagoe]

Pavel Lepin :

I hope you don't mean you serve XML documents with xml-stylesheet PI's. As
a rule of the thumb, that's a bad idea. Transform server-side and serve
HTML 4.01 Strict instead. The reasons have been discussed half a zillion
times in the past on this newsgroup, as well as on several others.

Perhaps, but I have so far been unable to find a comprehensive discussion,
only mentions of poor or no support in brand X browser, security
considerations preventing the two documents from coming from different
sources, MIME types, etc, none of which I see as a problem serious
enough to outweigh the advantages of pure XML applications serving static
documents or results from XQuery requests to a XML database without any
PHP, SQL or what not.

Could anyone provide a link, or explain why this cannot be a good approach?

 

[Joe Kesselman]

Could anyone provide a link, or explain why this cannot be a good approach?

I've got to agree -- Pavel, that's the first I've heard the "just don't"
suggestion described as a blanket consensus rather than as a "be aware
of these issues" item. If there's really a consensus, it predates my
starting to monitor this newsgroup, which I grant was only a few years ago.

I too would like a pointer to a better explanation of where you're
coming from. Not saying you're necessarily wrong, just that I don't know
that you're right.

(And this despite the fact that I'm currently in IBM's Datapower group,
a large part of whose business is in accelerating stylesheet processing
by offloading it to an optimized processor running on a dedicated box.)

 

[Johannes Baagoe]

Joe Kesselman :

... accelerating stylesheet processing by offloading it to an optimized
processor running on a dedicated box

One of the advantages of serving the document in XML with a XSLT transform
to be applied by the client is that it may dispense from such extremes.
Let the clients do the job, it saves processing on the server, and it
automatically scales if many clients connect at the same time.

I would actually go as far as to say that the relative sizes of the XML
document and the presentation resulting from its transformation is a
plausible measure of the site's signal / noise ratio... Keeping them
separated saves bandwidth, since the XSLT transform is often the same
for many pages if not all, and can therefore be cached. One may even use
the document() function to include recurring elements like menus, headers
or footers, and get them cached, too.

 

[Philippe Poulard]

Mark a écrit :

Mark a écrit :

Hi,
I'm developing my website using XML + XSLT. I'd like to insert some
data into my XML from a MySQL database. Typically I would do this
with PHP, but my web server doesn't seem to support PHP in *.xml
documents. Is there another way I could do this?
For example, I would like to do something like
// header data
<blog>
<?php
$result = mysql_query("SELECT * FROM blog");
while($row = mysql_fetch_assoc($result)) {
$title = $row['title'];
$descrip = $row['descrip'];
$article = $row['article'];
echo "
<title>$title</title>
<descrip>$descrip</title>
<article>$article</article>
";
}
?>
</blog>
// footer data
or something that produces the same effect. It would be even nicer if
I could somehow use XSLT to rewrite the XML so that I could have tags
like
<sql:query="SELECT * FROM blog"/>
<sql:for-each-row>
<title><sql:value-of select="title"></title>
...
</sql:for-each-row>

Active Tags can do that.http://ns.inria.org/active-tags/

If you are an XSLT user, you might be familiar with XPath ; in Active
Tags, most objects behave as XML and are accessible with XPath :
<sql:connect name="mySQLdb" url="..."/>
<sql:select name="blog" connection="{$mySQLdb}" query="SELECT * FROM blog"/>
<xcl:for-each name="row" select="{$blog/*}">
<title>{$row/title}</title>
</xcl:for-each>

But maybe I'm just dreaming...

RefleX is the name of the implementation of Active Tags

Have a look here :http://reflex.gforge.inria.fr/tutorial-fromSqlToMvc.html#sql
and have the RefleX !

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |

This looks neat, but I have no idea how I might get this running on my
server (I don't own the server). Thanks though!

It works on any server that support servlets, such as tomcat or jetty

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !

 

[Pavel Lepin]

<[email protected]>:

[serving XML with xml-stylesheet PI in WWW context]

I've got to agree -- Pavel, that's the first I've heard
the "just don't" suggestion described as a blanket
consensus rather than as a "be aware of these issues"
item. If there's really a consensus, it predates my
starting to monitor this newsgroup, which I grant was only
a few years ago.

Contrary to my previous post, this issue doesn't seem to be
well-covered neither here nor in
comp.infosystems.www.authoring.* hierarchy. So it's by no
means a consensus, just my own somewhat-religious opinion.

(Disclaimer to save me the trouble of IMO'ing every
sentence: the rest of my comments in this post represent my
own professional opinion, not the consensus among the
regulars of the relevant newsgroups as well.)

I too would like a pointer to a better explanation of
where you're coming from. Not saying you're necessarily
wrong, just that I don't know that you're right.

For me it's a 'just don't' that really is 'don't unless you
know very well how, why and what's to be afraid of', and it
only applies in WWW context. In controlled environment
serving XML styled with XSLT is just fine, - but the OP was
talking about a website, not an intranet application.

It really boils down to poor UA support. There are various
other reasons sometimes cited as well (such as loss of
incremental rendering, which I personally think is a weak
argument against the practice; impossibility of a graceful
degradation without some serious server-side mojo; and
somewhat more troublesome debugging), but all of those are
really secondary to the vendor support issue. So my strong
recommendation against serving XML to end-users follows
from those points:

1. In WWW context, we cannot safely assume the UA has the
capability to transform XML.
2. In WWW context, it is hard to gracefully degrade to a
different representation in case the UA in question is
incapable of handling our XML+XSLT.
3. In WWW context, any sort of graceful degradation would
likely boil down to the same old HTML 4.01 Strict
anyway. Since XML+XSLT offers few tangible advantages
over HTML 4.01 (the only one that comes to mind is
modest bandwidth economy thanks to the fact that we can
cache XSLT stylesheet and serve only pure data to the
end-user), I don't see any reason to maintain two
representations instead of just one.
4. And lastly, in WWW context, we generally want our
content to be accessible to the maximum number of users,
which for the time being means semantically marked-up
HTML 4.01 Strict styled with CSS.

I probably should note that I haven't been doing a lot of
website development in the last few years, apart from some
purely personal projects; but I'm using both w3m and Pocket
MSIE a lot in everyday life, so the issue discussed deeply
concerns me as a user.

 

[Pavel Lepin]

I hope you don't mean you serve XML documents with
xml-stylesheet PI's. As a rule of the thumb, that's a bad
idea. Transform server-side and serve HTML 4.01 Strict
instead. The reasons have been discussed half a zillion
times in the past on this newsgroup, as well as on
several others.

[snip]

If I can get XSLT to do all my dirty work, I may not need
PHP at all.

XSLT is not and was not ever meant to be a general-purpose
language. It's a domain-specific language for transforming
XML documents, therefore it's only natural that it lacks
facilities for interaction with the software that it's
operating in the context of (such as http server).

Yes, I am transforming the XML client-side. Which method
do you recommend for doing it server-side? Could you
point me in the right direction?

There are specialised software suites for this, but since
you seem to have very little to no control of your web
server configuration these are probably irrelevant to you -
and I've never used those software packages myself anyway.

Reflex/Active Tags sounds like what I was looking for, but
it might be a little tricky to get working on my server.

Cannot say anything for or against it.

I guess my last option is to do it all with PHP. I hope
it isn't too horrible to implement...

If you use PHP5 and XSL extension is enabled, transforming
XML document is just a few lines of code:

<?php
$xml = new DOMDocument () ;
$xsl = new DOMDocument () ;
$xml->load (XML_FILENAME) ;
$xsl->load (XSL_FILENAME) ;
$xsltProc = new XSLTProcessor () ;
$xsltProc->importStylesheet ($xsl) ;
print ($xsltProc->transformToDoc ($xml)->saveHTML ()) ;
?>

PHP4 has XSLT extension, which uses Sablotron transformation
engine. Sablotron doesn't seem to be maintained anymore,
and had a number of problems last time I looked at it.

 

[Philippe Poulard]

Pavel Lepin a écrit :

If you use PHP5 and XSL extension is enabled, transforming
XML document is just a few lines of code:

<?php
$xml = new DOMDocument () ;
$xsl = new DOMDocument () ;
$xml->load (XML_FILENAME) ;
$xsl->load (XSL_FILENAME) ;
$xsltProc = new XSLTProcessor () ;
$xsltProc->importStylesheet ($xsl) ;
print ($xsltProc->transformToDoc ($xml)->saveHTML ()) ;
?>

And if you have to produce an arbitrary-complex XML structure by mixing
XML litterals with several query results from several data sources (SQL,
LDAP, native XML databases, etc) it will become quickly a pain.

Active Tags/RefleX have been designed for that purpose ; it looks like
XSLT but instead of having a single instruction-set, several ones can
cooperate, and unlike XSLT, it is not specialized on a specific task.

Moreover, lots of processing-oriented markup languages have been
designed so far, and the more often they are declarative languages, such
as SCXML, XProc, or even W3C XML Schema, Oasis XML catalogs and many
others... Declarative languages are in essence very concise and
expressive but limited to what is allowed by the semantic of the
language. To go beyond those limits, Active Tags allow to mix
declarative constructs with imperative sentences, which leverage the
expressiveness of such declarative languages. Active Tags act as a
runtime container for several processing-oriented markup languages.

You can do many things like PHP does with Active Tags/RefleX, but you
will be able to achieve other things very simply that would be very
complex with PHP ; just use the tool the more suitable to your needs.

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !

 

[Joseph Kesselman]

It really boils down to poor UA support.

OK, so there are several choices:

Style on the server
Serve XML and style on the client
Intelligently switch between the two (the server knows what the client
is, and can decide whether it trusts the client's processor)
Offer the user their choice

My personal take is that we're in the same position we were before folks
started demanding more consistant behavior from HTML rendering, and the
proper response is the same: try to drive the clients to properly
support the specs, make them compete for users on that basis, and
provide fallbacks for those users who aren't willing/able to upgrade
(thought the fallbacks may not offer all the bells and whistles.)

We probably want to serve XML to customers, for aggregation and
automation and smart clients and so on. We probably want to serve
(X)HTML as well for those who can't yet do the right things with XML.
There's no either-or decision here, just one of prioritizing your needs.

Server-side styling is clearly the way to go in some cases.
Client side styling ditto.
Tools for tasks.

Absolutes are always inherently false, including this one.

 

[Mark]

Pavel Lepin a écrit :



And if you have to produce an arbitrary-complex XML structure by mixing
XML litterals with several query results from several data sources (SQL,
LDAP, native XML databases, etc) it will become quickly a pain.

Active Tags/RefleX have been designed for that purpose ; it looks like
XSLT but instead of having a single instruction-set, several ones can
cooperate, and unlike XSLT, it is not specialized on a specific task.

Moreover, lots of processing-oriented markup languages have been
designed so far, and the more often they are declarative languages, such
as SCXML, XProc, or even W3C XML Schema, Oasis XML catalogs and many
others... Declarative languages are in essence very concise and
expressive but limited to what is allowed by the semantic of the
language. To go beyond those limits, Active Tags allow to mix
declarative constructs with imperative sentences, which leverage the
expressiveness of such declarative languages. Active Tags act as a
runtime container for several processing-oriented markup languages.

You can do many things like PHP does with Active Tags/RefleX, but you
will be able to achieve other things very simply that would be very
complex with PHP ; just use the tool the more suitable to your needs.

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |

My server is running PHP 5.2.1 but it doesn't seem to support
XSLTProcessor. There's no library or something that I could simply
include is there?

---
One point I would like to make though, is that another benefit of
having the client do the transformations is that they can also use the
XML however they like...like in an RSS feed. Although I'd have to
look into that some more... there might need to be a few differences
between the web page and the feed.

And with regards to do "there is no guarantee the client will be able
to do the transformations"... what percentage of users is actually
*not* supported? Are not most people running modern browsers these
days? I don't expect my site to become immensely popular, if I
exclude a few people, it's not my biggest concern, although it is one
I would have to take into consideration after weighing the pros and
cons.

 

[Pavel Lepin]

It's a question of good design and module expertise. PLs
come in two varieties: those that you can produce
undecipherable code in, and those that are completely
unusable. While the dichotomy mystifies me somewhat, I've
learned to accept it as a simple fact of life.

[...]

My server is running PHP 5.2.1 but it doesn't seem to
support XSLTProcessor. There's no library or something
that I could simply include is there?

Not to my knowledge. I'm unaware of any pure-PHP XSLT
implementations, and even if there were one, it'd likely be
incomplete and awfully slow, so I would recommend against
it. If you're unable to affect the server's configuration
it would seem you won't be able to transform server-side.

One point I would like to make though, is that another
benefit of having the client do the transformations is
that they can also use the XML however they like...like in
an RSS feed. Although I'd have to look into that some
more... there might need to be a few differences between
the web page and the feed.

There's nothing that prevents you from serving the raw feed
separately.

And with regards to do "there is no guarantee the client
will be able to do the transformations"... what percentage
of users is actually *not* supported? Are not most people
running modern browsers these days?

Pocket MSIE on my PDA is a modern browser. So is w3m. So is
Konqueror. None of them are capable of rendering XML
documents served with xml-stylesheet PI's.

I don't expect my site to become immensely popular,
if I exclude a few people, it's not my biggest concern,
although it is one I would have to take into consideration
after weighing the pros and cons.

That's your decision, naturally.

 

[Pavel Lepin]

Pavel Lepin wrote:

[serving XML with xml-stylesheet PI in WWW context]

Style on the server
Serve XML and style on the client
Intelligently switch between the two (the server knows
what the client is, and can decide whether it trusts the
client's processor)

Actually, the server *doesn't* know what the client is, what
with UA's lying about themselves in User-Agent headers and
corporate proxies mangling request headers to prevent
divulging information that might lead to discovery of
attack routes for their internal networks (yes, that's
security-through-obscurity; and yes, that's a fact of life
whatever we might think about it). But that's beside the
point, because maintaining the capability tables is wrong,
hair-raising, mind-boggling and, ultimately, just plain
impossible. We tried that in the 90s when we didn't know
what the heck we were doing.

So all we really know is the Accept header (if the proxy was
so kind as to leave it be), and as far as I can tell
there's absolutely no indication there whether the UA will
be able to properly transform and render the text/xml that
it is so cheerfully willing to accept.

Offer the user their choice

I wouldn't think Joe U. Average would be particularly
thrilled by choosing 'HTML version' or 'XML+XSLT version'
upon visiting a website, especially given the fact that Joe
U. Average does not know and has no desire to know what all
that gobbledygook means. Again, choosing versions was
something we did back in the 90s. Nowadays, no one in their
right mind does that anymore. It's either graceful
degradation, stripping of the unnecessary gimmicks to
ensure maximum coverage or, for some delinquents,
displaying something along the lines of 'You need
WonkaWonka 2.3.15+ support to view this page'.

My personal take is that we're in the same position we
were before folks started demanding more consistant
behavior from HTML rendering,

Largely, we are. Note that even HTML+CSS rendering is still
not truly consistent, even in Standards mode, even across
major user-agents only. Things *have* improved greatly on
that front, there's no doubt about that.

and the proper response is the same: try to drive the
clients to properly support the specs, make them compete
for users on that basis,

The problem is that, IME, if User A cannot use Service B due
to many faults of his User-Agent C, he's not going to blame
the vendor of the user-agent. He's going to blame the
provider of the service. Arguably, he'd be right, too.

and provide fallbacks for those users who aren't
willing/able to upgrade (thought the fallbacks may not
offer all the bells and whistles.)

People in business of selling plane tickets to the
travellers are supremely uninterested in evangelising to
user-agent vendors. Come to think of it, isn't that
perfectly understandable of them? So it's either losing
some of the potential clients (and no businessman is going
to like that), or investing into designing and implementing
a system of fallbacks with little return (and no
businessman is going to like that either). Mind you, I'm
all for industry standards, but a standard is not an
industry standard until it's well-supported in the
industry. I'm also all for new and improved industry
standards, but I feel it would be unethical to promote
those at the expense of my employers, or worse, at the
expense of the employers of the people I'm giving advice
to.

We probably want to serve XML to customers, for
aggregation and automation and smart clients and so on.

Right, like I'm going to argue about that. Yes, we do. No,
convincing our employers to go with that before we can rely
on widespread support is not the right way to achieve the
desired results. Morally, if not otherwise.

Server-side styling is clearly the way to go in some
cases. Client side styling ditto.
Tools for tasks.

Absolutes are always inherently false, including this one.

Absolutely. <smirk/> Yes, even in WWW context there are sets
of requirements where going with serving XML+XSLT would be
the right thing to do. Those are rare.

I'm often sticking to absolutes when giving advice on the
newsgroups because people capable of making the right
choice in situations like this don't need my advice. They'd
be perfectly aware of the pros and cons, or capable of
doing all the needed research and reasoning and doing the
right thing afterwards, and my reiterating all the many
facets of the problem in question would be entirely
superfluous.

Now, people new to the field often take advice in the form
of 'foo is the right thing to do in most cases, but there
are these and those reasons that might make bar useful
under some circumstances' as an excuse to do bar anyway,
even when it's the wrong thing. Because they want to, and
don't understand (yet) whatever problems there might be
with bar approach.

ObXSLT: Compare with my Religious Hatred of xsl:for-each.
When talking about it, I just say 'Don't use it. Ever. It's
evil.' People capable of using it properly don't need my
ramblings, and likely are independent enough thinkers to
ignore any sermon I might be spewing forth. But if I
started explaining that *sometimes* it's the right and
goodly thing to do, someone would surely nest gazillionteen
xsl:for-eaches in <xsl:template match="/"/> and say it was
one of those cases. Like bloody hell it was.

Now, entirely OT: what does ObFoo really parse to? I'm
entirely Oblivious to the meaning of this Obscure
Obfuscation, and been unable to Obtain any sources of
relevant information by googling.

 

[Joseph Kesselman]

Actually, the server *doesn't* know what the client is, what
with UA's lying about themselves in User-Agent headers

If they lie in such a way that they claim capabilities/compatabilities
they don't have, that's their problem. If they lie in such a way that
the correct results occur, the lie doesn't matter.

point, because maintaining the capability tables is wrong,
hair-raising, mind-boggling and, ultimately, just plain
impossible. We tried that in the 90s when we didn't know
what the heck we were doing.

Right. And the need faded away as the browsers got better about
consistantly supporting the standards. Same thing will happen here,
though I grant we're in a somewhat awkward transition period.

I wouldn't think Joe U. Average would be particularly
thrilled by choosing 'HTML version' or 'XML+XSLT version'
upon visiting a website

They're already used to chosing flash/nonflash. They used to choose
frames/noframes. While I agree that it's *preferable* to do it all
automatically, I'm a firm believer in not letting the quest for the
perfect drive out the good enough. If in doubt, make the entry page the
most general one and encourage them to switch to the most efficient if
they can.

The problem is that, IME, if User A cannot use Service B due
to many faults of his User-Agent C, he's not going to blame
the vendor of the user-agent. He's going to blame the
provider of the service. Arguably, he'd be right, too.

Depends on the specific customers you're serving. In many business
environments, it is perfectly reasonable to say "The corporate standard
browsers are X and Y; if you use anything else our internal websites may
not work as expected." If you're serving folks who have no interaction
with you except the website, that's a different kettle of worms and you
may want two completely separate URIs for the website-as-website and the
tooling-via-XML paths... but if you're going to offer the latter,
there's no harm done in providing references to suggested stylesheets as
well so the XML *can* be rendered nicely by tools which support that hint.

Like I said, tools for tasks.

I'm often sticking to absolutes when giving advice on the
newsgroups because people capable of making the right
choice in situations like this don't need my advice.

Whereas I would prefer to either point the relative newcomers to
information that will help them learn to make the right choice...
especially since they rarely give us enough information to allow
offering a flat recommendation. And if I'm going to state an opinion, I
try to remember to make clear that it is one and explain it enough that
they can say "great, but that doesn't apply because..."

Now, people new to the field often take advice in the form
of 'foo is the right thing to do in most cases, but there
are these and those reasons that might make bar useful
under some circumstances' as an excuse to do bar anyway,
even when it's the wrong thing.

Not my job to cure that bad habit, or to try to anticipate it. I'm
willing to give some advice for free, but mindreading services are
available only on a billing basis.

ObXSLT: Compare with my Religious Hatred of xsl:for-each.

Which I still consider overstated to the point of being misleading. I
understand the point you're trying to make, but I think by putting it
that way you're actually substantially weakening your argument and *may*
be doing more harm than good.

Keep doing it if you really feel it's necessary; I'll keep filling in

Now, entirely OT: what does ObFoo really parse to?

Obligatory Foo. I picked it up in rec.music.filk, where offtopic
discussions are often jokingly justified by referencing them to a song
on a related topic, or by restating them in that form.

 

[Pavel Lepin]

If they lie in such a way that they claim
capabilities/compatabilities they don't have, that's their
problem. If they lie in such a way that the correct
results occur, the lie doesn't matter.

User-Agent header doesn't contain all that much useful
information, seemingly *by design*, and is easily (and
commonly) overridden, either locally or somewhere between
the client and the server. Compatibilities UA's tend to
claim stretch the very term a bit as well.

They're already used to chosing flash/nonflash. They used
to choose frames/noframes. While I agree that it's
*preferable* to do it all automatically,

I consider version choosing to be among the worst practices
in web development (at least when it's a required step, or
when the default version is the most demanding one; but I'm
not very fond of other options either).

As a side note, reasons why frames should be avoided and
flash used only when it's an inseparable part of content
offered *are* easy to find by googling.

I'm a firm believer in not letting the quest for the
perfect drive out the good enough.

Same here. It seems that only our definitions of 'good
enough' differ (for you, offering the richest user
experience possible at the cost of a little
inconvenience/confusion, for me, smoothest and most
straightforward user experience).

If in doubt, make the entry page the most general one and
encourage them to switch to the most efficient if they
can.

That *is* workable from the user's POV, but I believe it
might be hard to justify the costs.

Depends on the specific customers you're serving. In many
business environments, it is perfectly reasonable to say
"The corporate standard browsers are X and Y; if you use
anything else our internal websites may not work as
expected."

Now, now, that's why I was constantly mumbling 'in WWW
context' upthread. Yes, in controlled environments placing
strict requirements on the remote platform often does work.

(Even then, controlled environments are occasionally less
controlled then one might be led to believe. I've seen an
automated CS workplace system being developed in-house
under the assumption that the users would be working in
Firefox 1.5.x only. The result was a rather rich, and
rather thick client that relied heavily on implementation
details of Mozilla's products (Gecko, SpiderMonkey). Six
months down the road the supervisor suddenly realised he
really needed to use his BlackBerry to perform any number
of tasks. That would've been a serious failure on customer
requirements analysts' part, if only there was even one of
those on the team.)

If you're serving folks who have no interaction with you
except the website, that's a different kettle of worms and
you may want two completely separate URIs for the
website-as-website and the tooling-via-XML paths...
Absolutely.

but if you're going to offer the latter, there's no harm
done in providing references to suggested stylesheets as
well so the XML *can* be rendered nicely by tools which
support that hint.

Again, there's no reason not to. I suppose that, yes, if
we're transforming server-side anyway, and the abstraction
layers are properly separated, the costs of giving the
users access to raw XML feeds complete with relevent
stylesheets are negligible.

Whereas I would prefer to either point the relative
newcomers to information that will help them learn to make
the right choice...

[Either something is missing in that sentence. '...or lay
out a detailed perspective of the problem?']

Been there, done that. Doesn't do my blood pressure any good
to watch someone jump off the cliff right after I explained
why that mightn't be all that bright an idea without a
parachute. I somehow feel it's my fault for not explaining
the catch well enough, while if they do that after my
saying 'Don't jump off the cliff', they're obviously beyond
redemption.

Well, there's also the fact that truly useful analysis of
options based on limited information provided would often
amount to a treatise a few dozen kilobytes long.

(Sorry if I'm talking to myself there - had to guess the
alternative from my observation of your posts here.)

especially since they rarely give us enough information to
allow offering a flat recommendation.

Once the ball is in their court, they may supply whatever
additional information might affect that flat
recommendation of mine, or ask for further explanations if
they're truly interested.

And if I'm going to state an opinion, I try to remember to
make clear that it is one and explain it enough that they
can say "great, but that doesn't apply because..."

I don't think that's strictly necessarily. Of course it is
an opinion! What else could it be, a commandment? We're
geeks, not prophets. Even if we feel strongly about our
opinions, or jokingly *do* refer to them as to
commandments, we don't really mean it, now do we?

Which I still consider overstated to the point of being
misleading. I understand the point you're trying to make,
but I think by putting it that way you're actually
substantially weakening your argument and *may* be doing
more harm than good.

I'm not sure that's the best possible approach myself. Well,
I'm sticking to it for the time being anyway.

Keep doing it if you really feel it's necessary; I'll keep
filling in the explanations and qualifications you leave
out. <smile/>

Fine by me. It's probably more efficient as well, since you
seem to be much better at resisting the urge to bite
someone's head clean off when they're being a little
thick.

Obligatory Foo. I picked it up in rec.music.filk, where
offtopic discussions are often jokingly justified by
referencing them to a song on a related topic, or by
restating them in that form.

Ah, much Obliged. Should've been Obvious to me.