[whatwg] Element level XML and XSL attributes

On Tue, 2010-06-22 at 10:31 +0200, Julian Reschke wrote:
> On 22.06.2010 04:46, Dr. Clue wrote:
> > Having immensely enjoyed using w3.org standard XML/XSL
> > transforms in my web projects , I would really like
> > the HTML5 spec to consider the addition of two
> > element level attributes (XML and XSL)
> > ...
> 
> For the record: this sounds like a nice thing to have.
> 																								
> I recall that we seamless iframes were added as a mechanism to do 
> client-side includes; maybe there's a way to extend this to make this 
> work for XSLT-transformed XML as well? (I believe it should already work 
> throught he stylesheet PI, but programatically changing the XSLT 
> reference might be hard).
> 
> Best regards, Julian


I sorta want the option to have my transform results be part of the
main DOM tree and not be forced to live in what I might term a DOM
ghetto (object,iframe) with a so-called "separate but equal" status. :)

It would also be nice to have an XML element to go with the XML and XSL 
attributes. The basic effect of the XML element would be that
it itself had no effect on the tree and only the transform results
appeared in the tree functionally as related to layout parsing.

So for example one could have perhaps things like these.

<select name="foo" xml="http://somedatasource"
xsl="http://somexslsource" >
</select>

or in another situation have

<select name="foo" >
<option name="whatever1">static1</option>
<option name="whatever2">static2</option>
<option name="whatever3">static3</option>
<xml xml="http://somedatasource" xsl="http://somexslsource" />
</select>
`                                                                               

<div xml="http://search.twitter.com/search.atom?lang=en&q=devo&rpp=15"
xsl="formattwitterstuff.xsl" />


<div id=foxfeed"
xml="http://feeds.foxnews.com/foxnews/latest?format=xml"
xsl="formatfoxnews.xsl" />


Being as the xml and xsl attributes were separate, I could
easily switch between differing levels of detail in reading the 
news feed by simply applying a different stylesheet.

<div id="calender" xml="somecalenderdata.xml" xsl="monthview.xsl" />

Of course , here I could switch between month,week and day views
with a minimum of javascript overhead and not even have to reload
the calender data at all. That is totally different than 
if I had to tell the server to specify the xsl in the xml header,
and far less fooling around than if I have to have the javascript 
go fetch the new XSL file , do the transform and update the div.


How about a forum list

<div id="forumlist" xml="http:forumdata?page=1"
xsl="coolforumlayout.xsl" />


The server side forum program becomes simpler and of less load since it
is only having to provide the unique data, and not grind out every last
page element on every click. 

I could grind out use cases all day and not even build up a sweat.

Besides that , the workload for applications developers both server side
and client side becomes but a fraction of what it was without these 
XML/XSL items.

Content distributors should like it too , since a simple copy-n-paste
works for both the neophyte who can barely edit a page , as well as for
the rocket scientist who wants to reef on their content.

--Doc

Received on Tuesday, 22 June 2010 03:18:41 UTC