Bag of ideas and breaking the formatting-structure barrier

[Brett Zamir <brettz9@yahoo.com>]

Hello,

(My apologies if the following is already being worked on, but I haven't 
heard about it if it is...)

Even beginners to XML+styling/XHTML, especially those who are familiar 
with HTML, are turned off by the duplication of work needed to separate 
one's formatting from one's structure. The benefits to doing such 
separation are well-known, but it does come at a cost. Not only must one 
repeat information in order to cross-reference one document to another, 
but it can also a little bit harder to read one's own documents, if 
styling is important, when the styling is separated (at least if you're 
like me and likes to see all of the information right there together). 
Many times, we want to write XHTML/XML in a way which is simply like a 
brain dump—sticky note programs, for example, don't expect us to have 
our formatting separated while we dump our ideas. Why not devise systems 
that lets us be sloppy in our document creation process, but which 
predictably cleans it up for us (especially but not exclusively for 
those without server-side skills), whether within XML editing tools, 
server-side programs, or even more universally (though in some ways less 
efficient), server modules?

I was wondering about the potential for making an equivalent for 
XInclude (maybe "XPort"?) which allowed for XML content (including XML 
content containing CDATA such as CSS or scripting text but also 
elements) to be extracted from a document and appended to another 
document (with attributes indicating any desired sequencing). This would 
avoid the need for processing instructions targeting server-side 
programming and could work both with XML editing software—which might 
allow one to extract and remove all such elements and reassemble them 
into a new file—as well as by server-side software and ideally 
optionally, by the server itself and possibly in combination with the 
client (similar to Server-Side Includes, but without the use of comments 
and more like what we might call “Server-Side Excludes” whereby Xpath 
could either process all Xport statements or, if a header is sent by the 
client browser to it that it has already cached its Xport contents, be 
used to find and remove all Xport statements before serving them (to cut 
down on bandwidth as well as cluttering information)—to take advantage 
of increased network speed at “separating” (or more like 
cut-and-pasting) formatting from content).

These Xport statements could have their own target (temporary and 
domain-specific) file names—although I suppose they would probably need 
to be severely limited to certain filetypes like CSS or XSL, unless the 
fact of their privileges (e.g., for Javascript) being limited as with 
other remote content, could be well-understood by the system for 
security reasons. The target names would be generated by the receiving 
browser as temporary files (with some limits on the number of unique 
files that the browser would be willing to create for avoiding malicious 
servers locking up people's browsers by forcing them to do lots of file 
writing). While processing instructions could conceivably be used 
instead, I think XML would allow XML editors to better preserve 
coloring, etc. by allowing genuine child tags, rather than allowing XML 
content within processing instructions, for example.

<xp:moveto href=”newfile1.css”>
p.toc {color:red;}
div.header {background-color:blue;}
</xp:moveto>

Now, if XSL could include these statements, a document which combined 
style attributes or elements, for example, could be transformed with the 
styles shuffled off by the server software to a separate file while the 
main document was returned without the style information. One might even 
package XSL data and CSS data within one file which could be exported 
and then referenced for transformation by the same document (perhaps 
even as an attribute of the xp:moveto statement rather than requiring a 
new xml-stylesheet processing instruction).

This approach might also use attributes which would later be stripped 
but which could utilize the current element's information.

For example,

<p id=”mypar1” istyle=”font-weight:bold;”>

creates

#mypar1 {font-weight:bold;}

<div class=”toc “ eclstyle=”color:orange;”>

div.toc {color:orange;}

These attributes will be stripped but not before being transformed into 
a CSS statement which uses the current element's id, element name, 
and/or class, as a selector. If a class or id is called for by the 
attribute type used but no class or id exists on the element, one could 
be auto-generated. This allows a person, just as one may introduce a new 
abbreviation at the top of one's document, to use a style again later 
but without needing to initially write it globally or in an external file.

I realize that one could simply use XSL stylesheets to do the above, but 
the point here would be to be able to do it without converting one's 
document ahead of time or using server-side programming.

A few other different but related ideas...

Perhaps http headers could be made to support requests to the server to 
perform the transformation before sending.

Maybe processing instructions could instruct an XSL engine to first 
transform on the server-side.


If anybody is more curious about this approach, I used it (but not with 
XML, though it can be used to generate XML) in a plugin for the Smarty 
templating system that I made (based on someone else's plugin, 
SmartyDoc), and called it simply SmartyDocB:
https://sourceforge.net/projects/smartydocb
http://smartydocb.sourceforge.net/docs/documentation.xml

I can only think that such developments--while perhaps being looked down 
upon by purists who think documents should even be originally written 
with style separated from content, might hold more promise in weaning 
people away from HTML or transitional XHTML without so much of the pain.

I'd be eager to know if such approaches already exist or not, people's 
opinions, etc.

thanks and best wishes,
Brett