--- Martijn Tonies <m.tonies@...> wrote:

>
> > >>Only 5 years left for SQL, according to this
> man....
> > >>
> >
> >>http://otn.oracle.com/pub/columns/melton_sql.html
> > >>
> > >>...and XQuery is the future.
> > >>
> > >>..not sure myself
> > >>
> > >>
> > >
> > >Well, apparently SQL isn't all that, but
> XQuery??!!
> > >
> > >
> > I wouldn't waste a lot of time worrying about
> Melton.
>
> Didn't you say that about Celko either?
>
> ;-)
>
> --
> Martijn

some things about xml and web (ain't good for that
either)
from danielglazman (his cv
http://webperso.easyconnect.fr/danielglazman/CV_enDanielGlazman.html)

and the url with article

http://webperso.easyconnect.fr/danielglazman/weblog/index.php/Computing

"XML and the Web

This post expresses an opinion that many people share,
sometimes secretly because they belong to
standardization instances where this opinion is
considered to be a troll : XML misses an important
point to become the lingua franca of the Web. Whatever
the level of the "XML fever", our web sites are still
in (x)HTML, and if they are internally XML-based, we
don't see that XML.

Let me rephrase that : even if generic XML hit
successfully the market of data exchange, it has not
hit the Web yet despite of many years of existence,
and will not make it unless a few basic stuff are
added to XML. If those basic stuff are not added to
XML, the Web will move from HTML to XHTML but we won't
see other XML dialects on the Web (exception made of
RSS and consorts).

styles

Come on, I am not speaking of XSL here. Just
nobody uses XSL on the Web, and that fact is not
subject to major changes in the coming months, thank
Zeus. I am speaking of CSS. To apply CSS styles to an
XML document today, the following choices are
available (I am excluding protocol-based solutions):

* Use a processing instruction to attach a CSS
stylesheet to the document. Easy, reliable. Mucho
mucho more complex to handle when you have to add
dynamism to your document (movable objects,
programmatically positionable elements, ...)
* Use the XHTML style attribute declaring the
XHTML namespace and using xhtml:style

Wait!!! All XML documents can do the latter? Sure,
why do you ask? So the way of attaching inline CSS
styles to an arbitrary element in XML implies XHTML
knowledge? Yes, isn't it ironic that a generic XML
browser would have to know about a specific XML
dtd/schema to handle something as simple and useful as
inline stylistic data?

In my opinion, this is not only ridiculous but
also counter-productive. Inline styles are the only
reliable way to do wysiwyg copy/paste of information
between two documents without caring about the
context. And in some cases where the context matters a
lot, it's the only way. I think the style attribute
should be extracted from the XHTML namespace and
belong to the XML namespace, just like xml:id. That
way, no need for browsing/printing/editing tools to
have knowledge of XHTML to allow inline styles. Use it
or don't use it in your documents if you want, for
instance adding to your XML dialect's specification a
profile where the XML style attribute cannot be used,
but let it be available to anyone without knowledge of
XHTML.

Then we hit the problem of embedded stylesheets.
Embedded stylesheets are the stylesheets your can find
inserted into a style element in HTML documents. You
can't embed stylesheets into a generic XML instance.
Hell, again, why? Embedded stylesheets are extremely
useful on the web. A lot of super-useful bookmarklets
use them. A lot of dynamic sites use them. Correction,
a lot of dynamic HTML documents use them.

The xml-stylesheet processing instruction should
be extended to allow embedding of CSS stylesheets
(that's a proposal originally made, again, by Ian
Hickson I think).
classes

Are you a CSS author? I mean, do you have enough
basic knowledge of HTML and CSS to know what is a
class? If you have, you can skip the rest of this
paragraph. The class attribute is an attribute
available to almost all HTML elements. It contains a
list of white-space separated keywords that can be
used by CSS stylesheets to specify the styles that
should be applied to an element. If for instance the
rule p.foo { color: red; } applies to an HTML
document, all paragraphs in that document having their
class attribute containing the value "foo" (I say
containing because the attribute can contain more than
one keyword) will use the color "red" for their
text/foreground color. But the paragraphs having no
class attribute or not having "foo" contained in the
class attribute will NOT use that color. See how it is
useful?

So can you believe classes don't exist in XML?
Right. CSS has the notion of class selector (see
paragraph above for an example). CSS class selectors
were designed in a way so that CSS authors do not need
to know the name of the class attribute in the
document the styles apply to. The XML dialect should
provide that information. The XML dialect? Wait!!! So
what about well-formed documents? Hum, oh, argl. What
about xhtml:class?

Or what about fallbacking to
[mynamespace:myclassattr~="foo"]? Yes, why not?
Wait!!! If I do that, I can't make a generic
stylesheet applying a given class to all my XML
dialects without knowing the name of the class
attribute in each and every dialect of my collection!
Why do I have to use a steamroller to kill that
insect? Why can't I just write .foo { ... } ? Why
xml:id and not xml:class?

Come on again. Is that too hard to understand how
valuable is xml:class? Is putting the class attribute
into the xml namespace too expensive in terms of
namespace usage? Of course not. But the problem still
stands, and there is no valid reason why. The class
attribute should be in the XML namespace. Corollary,
why does it take seven years to solve such a
problem...
links

What a joke... But a sad joke. A foundation of the
Web is HYPERLINKS. And super-simple hyperlinks. Now,
take a look at the available mechanisms to make an
hyperlink in XML:

* XLink: I'll let others express my own
opinion... This is so unusable that the HTML Working
Group has kept anchors and links in XHTML 2.0. They
even have another proposal called HLink!
* XHTML namespace, again and again...

Hmm, that impression of d�j� vu... Why can't we
have the super-simple xml:href, xml:rel and xml:rev on
all elements of all XML dialects? To turn any element
into the source of an hyperlink? Yes, that's that
simple to do, and XHTML 2.0 proved it.
scripts

Aaaaah, scripts. The Web would not be without
scripts. And those who believe the contrary are even
more fanatics than the ones I mentioned just above.
The Web relies on scripts just everywhere. Right, it
relies on scripts everywhere because we failed
specifying declarative ways of doing what scripts
achieve programmatically. But scripts are so powerful
that I doubt it's possible to do all what they do
declaratively.

Anyway, declarative replacements for scripting are
not available today so let's deal with what we have
now. The question is simple : can I use scripts in
relationship with a generic XML document?. The answer
is no less simple: no.

What?!? Wait, so what's the point having that
superb DOM if it can only be used by chrome? And, and,
and... Yes. I know. Why do you think XUL has the
script element?

Oh, right, xhtml:script.... sigh... So is an
XML-ized Web supposed to have all its key features,
and by "key" I mean all the features that made the Web
really what it is today, come from the XHTML
namespace? That's total non-sense.

A generic XML way of using scripts is absolutely
and urgently needed. Make it simple, make it
xml:script.

In conclusion, I will say that we don't need a lot to
make it happen. Give me all the above and I abandon
XHTML right now. But that process is blocked that only
a few people I am not afraid to call fanatics, people
who close their eyes to pragmatism in the name of a
theoretical purity.

And it's just a shame.




__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html