OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] RE: James Clark: XML versus the Web

I'll bite on this ...
Conceptually, what is the difference between this suggestion (better CSS) then supporting XSLT in the browser ?

David A. Lee

-----Original Message-----
From: Ben Trafford [mailto:ben@prodigal.ca] 
Sent: Wednesday, December 01, 2010 11:49 PM
To: Kurt Cagle
Cc: liam@w3.org; Elliotte Rusty Harold; Amelia A Lewis; Michael Fuller; xml-dev@lists.xml.org
Subject: Re: [xml-dev] RE: James Clark: XML versus the Web

I don't disagree with any Kurt has said, but would like to repeat a
suggestion I've made elsewhere:

One of the big topics people seem to be avoiding is "Why does HTML still
promote native behaviors?" A lot of the issues with XML in the browser
simply go away if we can move HTML native behaviors to CSS.

For example: I can't declare a link in a browser in anything other than
HTML. Let's say I have a document...

<link uri="http://www.prodigal.ca";>This is Ben's webpage.</link>

Why could I not have a CSS stylesheet that looks like this?

link {
link-type: simple;
link-href: attr('uri');

This only addresses the question of links, but as we all know, there are
a host of behaviors in HTML that have never been disambiguated from the

We can address all the issues that have cropped as a result of
over-standardization, XML technologies that have matured at differing
paces, etc. Believe me, I would have -loved- to have Relax-NG back
twelve years ago when were thinking about XLink. I would've advocated
for making everything about XLinks into a schema-based datatype spec
that could be applied without any alteration of the pre-existing markup.

However, something everybody seems to be forgetting is that XML modules
are almost entirely optional. The XML spec requires very little
compliance with anything beyond the basics. You don't -need- to use DOM.
You don't -need- to use XSD. 

So, if what we're -really- talking about is "XML vs the Web", the first
place we need to start is not in tearing down all the old cruft, but in
figuring out what needs to be done to existing web technologies to make
XML on the Web workable, with a mindset to compatibility. 

I'd never argue, for instance, that we rend all the native behaviors out
of HTML -- it should still display those things natively. But if we
modified CSS to allow it to do everything HTML does natively, -and- to
override native behaviors, then we could have webpages made out of any
markup language people like. 

Imagine being able to apply web technologies to all the XML that largely
exists behind corporate walls -- ATA 2100 and the five billion documents
that Lexis-Nexis has, etc. 

I think that if we actually go back to basics (separating content from
behavior), we can come up with simple, elegant solutions that will make
XML on the web a reality without breaking any of the old stuff...crufty
or not.

And for my money, actually being able to display any markup I like with
all the power of HTML and its related technologies would be a grand
start that requires very little work, comparative to some of the
thornier issues I've seen bandied about the last week or two.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS